[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
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 !!!
- mailutils/IMAP, Alain Magloire, 2001/01/10
- Re: mailutils/IMAP, Jakob 'sparky' Kaivo, 2001/01/10
- Re: mailutils/IMAP, Alain Magloire, 2001/01/10
- Re: mailutils/IMAP, Jakob 'sparky' Kaivo, 2001/01/10
- Re: mailutils/IMAP, Alain Magloire, 2001/01/10
- Re: mailutils/IMAP (2), Alain Magloire, 2001/01/10
- Re: mailutils/IMAP (2), Jakob 'sparky' Kaivo, 2001/01/11
- Re: mailutils/IMAP (2),
Alain Magloire <=
- Re: mailutils/IMAP (2), Jeff Bailey, 2001/01/11
- Re: mailutils/IMAP (2), Alain Magloire, 2001/01/11
- Re: mailutils/IMAP (2), Harald Meland, 2001/01/15
- Re: mailutils/IMAP (2), Alain Magloire, 2001/01/15
- Re: mailutils/IMAP (2), Sean 'Shaleh' Perry, 2001/01/15
- Re: mailutils/IMAP (2), Jakob 'sparky' Kaivo, 2001/01/15
- mailutil/X-UIDL, Alain Magloire, 2001/01/15