bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mailutils/IMAP (2)


From: Alain Magloire
Subject: Re: mailutils/IMAP (2)
Date: Thu, 11 Jan 2001 00:42:26 -0500 (EST)

> 
> "Alain Magloire" <address@hidden> writes:
> 
> > I noticed that you no longer use the "preforked" scheme use in
> > the 0.9.8.  I do not know if it's good or bad(think it's good) since
> > this not totally portable to all architectures.
> 
> It should be good, provided it is coded right. The only reason 0.9.8
> and below preforked is because I was having problems creating proper
> fork-on-demand code. I was able to create some rather elegant fork
> bombs, however.

Ok. But there is a certain danger the way it is now.  Suppose I set
the number to of daemon to 5 after 5 connections all new connections
will backlog(listen()) and finally rejected.  This is intentionnal ?

> > All my changes to pop3d are commited, server seems to run without any
> > problems but I did not stress it either.
> > 
> > NOTE:
> > - UIDL is implemented in the library (message_get_uidl())
> >   the library tries to be compatible by searching an "X-UIDL" header
> >   if not send the "Message-ID".  But this is not right since message-id
> >   is an optionnal header(according to the rfcs), I should fallback instead
> >   to an MD5 or some other schemes ... for later.
> 
> I would suggest an MD5-based scheme (like MD5+someotherstuff) and
> setting the X-UIDL header if it isn't already there. I'll look into it.

Hmm, I'm suprise because I remember someone on this list behind strongly
against it since this will require to write() or some sort delay etc ..

I did not put code in the library yet for this, this will be on the next
round.

> > - Notice that other popd severs will skip the "Status:" fields and some 
> > other
> >   fields(TOP, RETR) maybe we should do the same.
> 
> The other POP3 serves are broken. ;) I don't think there is any
> compelling reason to not send any headers to the client, unless there
> is some client that depends on a Status: header not being sent, in
> which case its maintainers should be drawn, quartered, tarred,
> feathered, and then really hurt.

8-)
I think one of the reasons is they want the clients to see all messages
downloaded as new messages.  Since the "Status:" or the "X-Status:" by
the c-client is use for the flag attributes (deleted, seen, etc ...).

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]