Date: Mon, 17 Feb 1997 15:56:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: pst@shockwave.com (Paul Traina) Cc: hackers@freebsd.org, fetchmail-friends@snark.thyrsus.com Subject: Re: looking for QualComm qpopper testers to try new patch Message-ID: <199702172256.PAA09811@phaeton.artisoft.com> In-Reply-To: <199702172216.OAA28519@precipice.shockwave.com> from "Paul Traina" at Feb 17, 97 02:16:27 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I've got a patch to QualComm's QPOP 2.2 that generates Return-Path: lines > in place of the ommitted "From_" line information (which QPOP has incorrectly > ignored for years). This patch should work well with the newly updated > version of Fetchmail that now respects Return-Path: lines. The "From" line is dumped in when leaving an RFC821 transport. I believe you are (incorrectly) assuming that all your mail came from an RFC821 transport. RFC822 does NOT require a From line; in point of fact, it can cause errors on some clients, since the stamp is not necessarily the only way to seperate messages, and the From line is not a valid RFC822 header and may prematurely terminate RFC822 message parsing used to extract little things -- like, oh, say, "boundry=..." from a MIME header line indicating MIME encapsulation is occurring in the RFC822 message body. Anyway... > I'm looking for victims who UNDERSTAND THE POP PROTOCOL to test this patch. > I know it generates the Return-Path: properly, but I don't know if it is > handling the UIDL generation in a deterministic fashion (I hope it is). > > Note: UIDL's generated by this new version of QPOP include the Return-Path: > line in their calcualtion, whereas the old QPOP did not. Therefore on-the > fly UIDL generation is different in the new version, However, since QPOP > stores the first calcualted UIDL, this /shouldn't/ cause your MUA to think > old messages are now new again. > > Of course, that's what I need someone to test (since I don't use UIDLs). Download an older version of Netscape with the POP3 client (you should see RFC1939 for details). I'm kind of hesitant to consider "Return-Path:" in the UID generation; I would much, much prefer that a timestamp of the form: YYYYMMDDHHMMSSII (where II == instance for a given second) be placed in an "X-UID:" or a "Message-ID:" header by the transport (not generated on the fly by the QPopper). I don't think it's the QPopper's responsibility, I think it's the message store's responsibility, and sendmail is the (current) maintainer of your message store. A "Message-ID:" would be doubly helpful, in that it would allow threading of the (nominally SMTP-created) list archives... really necessary to make the archives even marginally useful. > If you don't know what a UIDL is, and why it's used, or you're not > sure your MUA is using UIDLs to determine which messages it has already > seen, then please don't bother testing this. Heh, sorry, my MUA doesn't use the UIDL Pop3 command to list UID's. > Things I need answered: > > (a) Did this cause you to download old messages left on server > as if they were new again? (hopefully not) > (b) If you leave mail on the server, do you get stuck downloading > that same message over and over again every time you start > your pop client. I have to say that this kind of empirical testing isn't very useful. Another mechanism, if you *must* generate "on the fly", is to generate a lexical index on user authentication to a particular maildrop, then MD5 the full message body. The timestamp from the SMTP will be different in any case (think SMTPd generation of "Apparently-To:" from the "RCPT TO:..." line). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702172256.PAA09811>