"Donna Slagle" <wookie@bright.net> wrote in message
news:n72dnfkTAqCPn67fRVn-uA@bright.net...
If you are using a Microsoft e-mail client, it can screw up if the mail
server fails on sending a mail item. Outlook polls your mailbox, starts
to download messages, gets hung up on a corrupted item in your mailbox
on the server, and never sends a DELE command at the end of the
[aborted] mail session to delete those messages that you did manage to
download. Because the already downloaded mails don't get deleted but
because the mail session failed, Outlook starts all over. Outlook first
issues RETR to retrieve a copy of your mail item, it retrieves all of
them first, and then later it submits a bunch of DELE commands to delete
them. However, if it never gets to the DELE commands because of an
aborted mail session, the aborted session causes Outlook to *not* keep a
record of the unique IDs for the messages that it already managed to
download and the messages remain on the server to look like new messages
on the next mail poll. Outlook really should issue the DELE command
right after the RETR command to prevent this hiccup. I haven't checked
but I suspect the same behavior is exhibited by Outlook Express and, I
suppose, possibly by other e-mail clients. Nothing in RFC 1939 dictates
the order of the POP3 commands regarding when to delete them after
retrieving them.
Another possibly is that the mail server is screwing up when it hits the
corrupted mail item. The e-mail client may submit the DELE command but
that only marks the status of the mail item as "deleted". That does not
immediately delete the mail item. The delete is pending until the mail
session changes from a transaction state to the update state. If the
mail server is screwing up, it could be it isn't honoring the DELE
commands from your e-mail client. The update state occurs after the
e-mail client sends the QUIT command (i.e., it ends the mail session).
If the mail server hangs or ignores the pending deletes, the messages
are still there. However, the e-mail client *should* already have the
unique ID for the mail item and not re-download it on a subsequent mail
session - *if* the mail server supports the UIDL command (which
retrieves the unique ID for each mail item). Otherwise, all the mail
server has to go on is the relative index number assigned to a mail item
and that is not unique. Item 2 becomes item 1 after item 1 gets deleted
but item 2 was not, and there are plenty of other ways in which the
index numbers get reordered. In that case, you need to contact your
e-mail provider (if the below instruction doesn't work). If, for
example, your e-mail client never sent the QUIT command, the mail server
may not imply one with the loss of the mail session so it never goes
into the update state. Because you noted the session got disconnected
with an error, this could be the cause of re-retrieving the same
messages. Turn on the troubleshooting log for your e-mail client to see
what commands it sends, what it gets back, when the RETR and DELE
commands get sent, and for any errors.
Use the webmail interface to your account, read the messages there, then
delete them all (which will get rid of whichever is the problematic mail
item). Outlook [Express] should work correctly thereafter as you
receive new mails.
If you have e-mail scanning by your anti-virus software, disable it and
retest. The mail server delivers the mail item after getting the RETR
command but the AV program is sucking up the output while the e-mail
client is kept waiting for delivery. So the e-mail client may timeout
and error because it doesn't see anything coming back from its RETR
command. Some AV products have an option, which should be enabled, to
prevent this timeout by sending an X-<something> dummy header to the
e-mail client at about 1-minute intervals to keep the e-mail client from
timing out (Norton's AntiVirus has this option; it should be enabled by
default). Disabling e-mail scanning by your AV program will eliminate
this lag in delivering the mail item to your e-mail client.
--
__________________________________________________ __________
Post your replies to the newsgroup. Share with others.
E-mail reply: Remove "NIXTHIS" and add "#VS811" to Subject.
__________________________________________________ __________
