At 07:41 PM 8/25/97 -0500, Philip Guenther wrote:
lists(_at_)professional(_dot_)org writes:
...
3. Some POP clients (Netscape and Pegasus are two I know of) apparently
add this field as part of their stored message (you see it locally, but it
wasn't transmitted that way) -- it is a separatley requested/generated
header from the mail server (used to uniquely identify the message for
storage/retrieval purposes). I prefer the way Eudora handles it -- since
The X-UIDL: header is not added by the POP client but by the POP
server. Read rfc1939, the POP3 rfc, and you'll see that the server
I hate to disagree with you here, but I'm still convinced that Pegasus DOES
apparently add the header from even servers which don't. Such a client app
can get the info using the UIDL command, then insert an X-UIDL header where
there was none. All three of the (separatley served) mailservers I'm using
don't insert the X-UIDL (I've done a RETR msgnum and checked), yet
associates using Pegasus AND THE SAME POP3 SERVERS, report that they have
X-UIDL in their stored messages.
If you look at your inbox from Netscape, you'll see an "X-Mozilla-Status"
header there too -- added by Netscape, not part of the original message,
not sent by the server. Same thing for X-PMStatus or something of the sort
for Pegasus. Locally added.
must generate a unique ID for each message that is static across
connections to the pop server. The qpopper (and I think the Berkeley
Upon reading the RFC in question, I agree that the header *MAY* be added by
the server, but (see the quote below), it doesn't say that it MUST be
stored in the message itself. Since the client software obtains the UIDL
value by using the UIDL command, and gets back JUST the UIDL, it is
full-well capable of storing the header in a modified state back into the
message when downloaded (after all, implementation of "retrieve just the
headers" and "leave mail on server" is handled very differently by most
mailers). If X-UIDL is how the server would store it, why shouldn't the
software add it as a temporary header, and if it isn't superceeded by the
downloaded message, continue to use the temporary header? This would allow
the software to treat the downloaded messages the same whether they are
coming from a server providing X-UIDL or not.
It would also lend some reasoning to why spammers would want the header
there to begin with -- because on servers not inserting the X-UIDL into the
header, the client could become confused and end up downloading the same
message multiple times (the bogus X-UIDL header not matching the ACTUAL
message UIDL), or leaving it on the POP server (I've seen this happen),
requiring the user to somehow manually delete the messages.
[quoted from RFC1939]
"While it is generally preferable for server implementations to store
arbitrarily assigned unique-ids in the maildrop, this specification is
intended to permit unique-ids to be calculated as a hash of the message.
Clients should be able to handle a situation where two identical copies of
a message in a maildrop have the same unique-id."
From this, I would infer that the servers I happen to use choose to
implement a hash instead of modifying the maildrop. Thus, at least for the
time being (until they change their method), *I* am safe to continue
filtering on the header.
So, once again I reiterate, your mileage may vary.
the field IS NOT PART OF THE MESSAGE, it IS NOT STORED WITH THE MESSAGE.
This is server dependent.
Apparently.
But, would this header be generated when the message is placed into the
maildrop or after the user has checked mail using a POP3 client (which
could lead to "sometimes you see it, sometimes you don't" on a server which
does add the header). And in either case, wouldn't this be AFTER procmail
was called as a local delivery agent to attempt delivery?
If you use fetchmail to get your mail from a pop server that inserts
the X-UIDL: header, than every message you get will contain the X-UIDL:
header. However, this is a relatively rare set up, and You Know Who Are.
The rest of us can use it to filter spam.
Good to know :)
-- Sean (I'm marking this message thread for future reference) Straw
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395