[Top][All Lists]

[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

> > - 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.

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]