"Samantha Eaton" said in news:
[email protected]:
Time to do some reading of RFC 1939, "Post Office Protocol".
STAT should return:
+OK nn mm
where nn is the number of messages and mm is their aggregate size (as
octets).
LIST returns a list of the messages, as in:
+OK 2 messages (320 octets)
1 120
2 200
.
The period character at the start of the line indicates end of data. The
first number is just the relative position of the message in the queue,
*not* is unique message identifier. If STAT returns 3 but LIST returns only
2 in its list, obviously the mail server is screwed up.
UIDL (with no arguments) is similar to LIST in that it returns a list of
messages:
+OK
1 whqtswO00WBw418f9t5JxYwZ
2 QhdPYR:00WBw1Ph7x7
It also shows the relative message position value of each message as in
LIST. However, the second value is the unique message ID. If the e-mail
client only downloads the headers (and not the body) then this messageID can
be used to delete the message without ever having to download its contents.
For the lifetime of a mailbox, every message received is supposed to get a
unique identifier (so those once use for messages that got deleted still
don't get reused), per the requirement in the RFC 1939:
"The unique-id of a message is an arbitrary server-determined string,
consisting of one to 70 characters in the range 0x21 to 0x7E, which uniquely
identifies a message within a maildrop and which persists across sessions.
This persistence is required even if a session ends without entering the
UPDATE state. The server should never reuse an unique-id in a given
maildrop, for as long as the entity using the unique-id exists."
So the count of messages returned by STAT should equal the number of
separate messages listed by LIST which should equal the number of separate
messages listed by UIDL (with no argument). If STAT reports 5 messages
total, LIST reports 4, and UIDL reports 12 then obviously something is very
farked on the mail server. The RFC says, "Note that messages marked as
deleted are not listed." Maybe the mail program is screwed up and reporting
delete-marked messages.
So has your client actually bothered to yet contact their ISP to find out
why the ISP's mail server is reporting different message counts for STAT,
LIST, and/or UIDL?
Turn on logging in the mail client and see the results returned by the STAT,
LIST, and UIDL commands sent by it to the mail server.
