Date: Mon, 17 Feb 1997 15:44:23 -0800 From: Paul Traina <pst@shockwave.com> To: Terry Lambert <terry@lambert.org> Cc: hackers@freebsd.org, fetchmail-friends@snark.thyrsus.com Subject: Re: looking for QualComm qpopper testers to try new patch Message-ID: <199702172344.PAA28691@precipice.shockwave.com> In-Reply-To: Your message of "Mon, 17 Feb 1997 15:56:22 MST." <199702172256.PAA09811@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Terry Lambert <terry@lambert.org> Subject: Re: looking for QualComm qpopper testers to try new patch > 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 incorrect >>ly > 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. I agree with you 100%. This converts the From_ line that is in a unix style /var/mail file into the LEGAL Return-Path: line. I've been involved in these fights for a long time (10 years?) and am just interpreting consensus. In any case, it's illegal to transmit a From_ line over a POP connection, IMO, but there is information loss (the envelope from) if you don't pass it some way. Return-Path: is the legal and well supported alternative. Anyway... Yes, since we're violently agreeing with each other. :-) > 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 No, you don't understand. QPOP computes the UIDL by calculating a MD5 hash across the entire message header (not including fields that can change, such as Status:). The server previously did not include the envelope from information in the hash (the From_ line). I am now including the Return-Path: line in the hash. I am just adding more data to the hash. Additionally, if a message is already in the spool file with an X-UIDL line in it, QPOP will use that computed value instead of recomputing its own, which is why I can get away with adding Return-Path: to the hash. I'd like the UIDL to simply be the message ID, but frankly, they are NOT unique, and the author of QPOP realized that too. (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. That can be extracted from the header already. > 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. Yep, I use MH myself. > 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. Actually, it is. It makes sure that the old UIDs are persistant across POP sessions, and that the new hash change didn't screw anything up, assuming that your MUA uses UID's as specified by POP3. :-) 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?199702172344.PAA28691>