Bad (blank) messages stopping Outlook

  • Thread starter Thread starter Bradley Plett
  • Start date Start date
B

Bradley Plett

This could be an Exchange bug OR an Outlook bug (or both). Hence the
cross-posting.

We are running Exchange 2003, and clients are accessing via Outlook
and POP3. Occasionally, completely empty messages (no sender, no
message, no body) will appear in mailboxes, and Outlook will choke.
We must then go into OWA, which clearly shows the message to be
completely empty, and delete the message before Outlook can receive
again. Has anyone encountered this problem before? Is there a
fix/work-around?

The message Outlook produces at that point is as follows:
----------
Task '(email account name) - Receiving' reported error (0x800CCC0F) :
'The connection to the server was interrupted. If this problem
continues, contact your server administrator or Internet service
provider (ISP). The server responded: +OK'
----------
The cause of the message isn't difficult to understand: the extra
blank line required by the POP3 protocol after the end of the message
body is missing. However, that doesn't help me in fixing the problem.

Looking at the internet headers, I'm not sure if I should be more or
less concerned. The internet headers on these phantom messages seem
to get corrupted when receiving the "Message-ID". Are there
users/bots out there sending partially corrupted messages? Is
Exchange causing the problem? Is my hardware flaky?

If I knew that a message that gets cut off in this manner sends an NDR
to the sender, or if the sender automatically retries in this
scenario, I'd stop worrying about it. However, I would still like to
keep emails like this from making it to user mailboxes. Is there a
way for Exchange to purge these messages before the client tries to
receive them?

Any help would be appreciated!

Thanks!
Brad.

P.S. This note may look familiar: I posted a similar one a month
ago, and another one a couple of months before that, but haven't made
any progress.

P.P.S. It is becoming increasingly clear that I am not the only one
experiencing this problem. If you do a search in this forum for
"blank" in the subject, a number of others are having the same issue.
Microsoft: can you help?

P.P.P.S. One suggestion I got was to use sender filtering. This
helps, but still doesn't solve the problem.
 
Bradley Plett said:
This could be an Exchange bug OR an Outlook bug (or both). Hence the
cross-posting.

We are running Exchange 2003, and clients are accessing via Outlook
and POP3. Occasionally, completely empty messages (no sender, no
message, no body) will appear in mailboxes, and Outlook will choke.
We must then go into OWA, which clearly shows the message to be
completely empty, and delete the message before Outlook can receive
again. Has anyone encountered this problem before? Is there a
fix/work-around?

The message Outlook produces at that point is as follows:
----------
Task '(email account name) - Receiving' reported error (0x800CCC0F) :
'The connection to the server was interrupted. If this problem
continues, contact your server administrator or Internet service
provider (ISP). The server responded: +OK'
----------
The cause of the message isn't difficult to understand: the extra
blank line required by the POP3 protocol after the end of the message
body is missing. However, that doesn't help me in fixing the problem.

Looking at the internet headers, I'm not sure if I should be more or
less concerned. The internet headers on these phantom messages seem
to get corrupted when receiving the "Message-ID". Are there
users/bots out there sending partially corrupted messages? Is
Exchange causing the problem? Is my hardware flaky?

If I knew that a message that gets cut off in this manner sends an NDR
to the sender, or if the sender automatically retries in this
scenario, I'd stop worrying about it. However, I would still like to
keep emails like this from making it to user mailboxes. Is there a
way for Exchange to purge these messages before the client tries to
receive them?

Any help would be appreciated!

Thanks!
Brad.

P.S. This note may look familiar: I posted a similar one a month
ago, and another one a couple of months before that, but haven't made
any progress.

P.P.S. It is becoming increasingly clear that I am not the only one
experiencing this problem. If you do a search in this forum for
"blank" in the subject, a number of others are having the same issue.
Microsoft: can you help?

P.P.P.S. One suggestion I got was to use sender filtering. This
helps, but still doesn't solve the problem.
Click to expand...

Brad,
Although some will tell you this is not right and can not work I and others
have thanked me.
Jim Nickerson
 
Well, I'm more than willing to give that a try! It sounds closer than
anything else I've found. :-S Unfortunately, I may never know
absolutely whether or not this fixes it, because these bad messages
are fairly few and far-between. If I haven't encountered any in
another year, I'll be optimistic that the problem has been solved.
:-)

Does anyone know whether the check happens when the message arrives,
or when the POP3 client tries to access it? Given the name and
location in the registry, I would assume this has to do with the POP3
service, and hence the check would happen when the POP3 client tries
to read the message. I made the registry change, and even rebooted to
make sure Exchange took the change. I then tried moving one of the
offending messages from the "Deleted Items" folder back into the in
box, and it promptly caused the problem with Outlook. So, if the
check is supposed to happen when the client accesses it, then sadly
this has not fixed the problem. However, I'll leave it this way for a
while and hope for the best.

Thanks!
Brad.
 
Sadly it didn't take very long to find out that this doesn't solve the
problem. :-(

I got a message today that caused the same problem. Any more ideas?

I still believe that this is a bug, and a case could be made that it
is a bug in BOTH Exchange and Outlook. Exchange should ensure that a
POP3 client gets the proper termination sequence, and Outlook should
be able to compensate if the server returns the "+OK". This second
one might be a little more difficult, since some dangerous assumptions
might have to be made, but....

Thanks!
Brad.
 
Back
Top