Date: Mon, 17 Feb 1997 17:03:55 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: pst@shockwave.com (Paul Traina) Cc: terry@lambert.org, hackers@freebsd.org, fetchmail-friends@snark.thyrsus.com Subject: Re: looking for QualComm qpopper testers to try new patch Message-ID: <199702180003.RAA09940@phaeton.artisoft.com> In-Reply-To: <199702172344.PAA28691@precipice.shockwave.com> from "Paul Traina" at Feb 17, 97 03:44:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. I still don't think a hash is the right way to go... 8-(. > 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. X-UID? ...UIDL: (Unique ID List) is a Pop3 command; the quantity being described is a UID, not a UIDL. > 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. ??? OK... why are the message Id's unique? Timestamp not included, maybe? > 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. :-) Well, for data which already exists. It won't cause a full branch-path code verification, which is really the type of test you want. All you will find out is that it doesn't screw your testers, not that it won't screw them or you in the future. That's a bad thing... 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?199702180003.RAA09940>