Phantom email

  • Thread starter Thread starter Lil' Abner
  • Start date Start date
L

Lil' Abner

I use Eudora for email.
I have Norton Internet Security installed.
A few minutes ago I got an email with no sender, no subject, and the body
contained 75 lines of the following.

X-Symantec-TimeoutProtection: 0
X-Symantec-TimeoutProtection: 1
X-Symantec-TimeoutProtection: 2
X-Symantec-TimeoutProtection: 3
etc., etc., all the way to 74

No headers of any kind whatsoever.
Google didn't have much in English about it, and what little I could
understand related it to "Spam Cop" which I don't have.

It's not the end of the world or anything, but I'm just curious if anyone
else has ever experienced it and tried to figure out what caused it.
 
Lil' Abner said:
I use Eudora for email.
I have Norton Internet Security installed.
A few minutes ago I got an email with no sender, no subject, and the
body
contained 75 lines of the following.

X-Symantec-TimeoutProtection: 0
X-Symantec-TimeoutProtection: 1
X-Symantec-TimeoutProtection: 2
X-Symantec-TimeoutProtection: 3
etc., etc., all the way to 74

No headers of any kind whatsoever.
Google didn't have much in English about it, and what little I could
understand related it to "Spam Cop" which I don't have.

It's not the end of the world or anything, but I'm just curious if
anyone
else has ever experienced it and tried to figure out what caused it.
Click to expand...


You are attempting to receive a HUGE e-mail. Norton AntiVirus tries to
prevent a timeout by your e-mail client when it doesn't receive status
from your mail server for awhile. Because you have e-mail scanning
enabled by NAV, the e-mail is first going to NAV for it to scan for
viruses, then it passes it off to your e-mail client. Meanwhile your
e-mail client is getting nothing returned from the RETR command it sent
to your mail server. If the e-mail client doesn't get a response from
the mail server, eventually it times out with an error. NAV tries to
prevent the timeout by sending its X header every so often (I think it
is every 60 seconds). If you are seeing 74 of these then the e-mail you
are trying to download and scan is ridiculously huge or the mail server
has stalled. The X lines are in the headers that your e-mail client
sees, not in the body of the message (because NAV hasn't passed the
message to your e-mail client yet).

My guess is that your mail server stalled and never returned anything
from the RETR command or got stuck part way through sending it. A
message that is corrupted on the mail server can stall it. Use the
webmail interface to your e-mail account, delete all messages, and send
some test e-mails to that account to test that the mail server works
okay again. Otherwise, you can disable e-mail scanning by NAV but it
looks like NAV wasn't the problem because it wasn't getting anything
from your mail server. Without NAV repeatedly sending its X header to
keep your e-mail client from timing out, you'll probably find that with
e-mail scanning disabled that your e-mail client would have aborted
eventually, like after 5 minutes.
 
You are attempting to receive a HUGE e-mail. Norton AntiVirus tries
to prevent a timeout by your e-mail client when it doesn't receive
status from your mail server for awhile. Because you have e-mail
scanning enabled by NAV, the e-mail is first going to NAV for it to
scan for viruses, then it passes it off to your e-mail client.
Meanwhile your e-mail client is getting nothing returned from the RETR
command it sent to your mail server. If the e-mail client doesn't get
a response from the mail server, eventually it times out with an
error. NAV tries to prevent the timeout by sending its X header every
so often (I think it is every 60 seconds). If you are seeing 74 of
these then the e-mail you are trying to download and scan is
ridiculously huge or the mail server has stalled. The X lines are in
the headers that your e-mail client sees, not in the body of the
message (because NAV hasn't passed the message to your e-mail client
yet).

My guess is that your mail server stalled and never returned anything
from the RETR command or got stuck part way through sending it. A
message that is corrupted on the mail server can stall it. Use the
webmail interface to your e-mail account, delete all messages, and
send some test e-mails to that account to test that the mail server
works okay again. Otherwise, you can disable e-mail scanning by NAV
but it looks like NAV wasn't the problem because it wasn't getting
anything from your mail server. Without NAV repeatedly sending its X
header to keep your e-mail client from timing out, you'll probably
find that with e-mail scanning disabled that your e-mail client would
have aborted eventually, like after 5 minutes.
Click to expand...

My email server is about 8 feet away, so after reading this, I went and
checked the logs. The last SMTP IN was an hour before this occured. That
was a message which was delivered normally and I had already read. The
POP log just showed my pop client checking mail every 8 minutes as it is
set to do, but indicating the mailbox was empty on each check. The
message I mentioned (with no headers) came at 22:22 (10:22 PM) which was
about halfway between my 8 minute checks. Your theory was good and I was
just trying to confirm it.... :-) I think I'll just add it to my
"unsolved mysteries" list and move on.
 
Lil' Abner said:
My email server is about 8 feet away, so after reading this, I went
and
checked the logs. The last SMTP IN was an hour before this occured.
That
was a message which was delivered normally and I had already read. The
POP log just showed my pop client checking mail every 8 minutes as it
is
set to do, but indicating the mailbox was empty on each check. The
message I mentioned (with no headers) came at 22:22 (10:22 PM) which
was
about halfway between my 8 minute checks. Your theory was good and I
was
just trying to confirm it.... :-) I think I'll just add it to my
"unsolved mysteries" list and move on.
Click to expand...


After supposedly sending the e-mail as a result of getting the RETR
command from the e-mail client, did your mail server actually send the
OK status after completing the send of the message? Since the
anti-virus program is intercepting the e-mail delivered by your mail
server, it probably won't pass it to your e-mail client until the mail
server finally responds with the "." line to indicate the end of the
message data (so the anti-virus program knows there isn't anymore
coming). Does the e-mail client's logs show ever getting the "."
termination line? Did it ever get the OK status after sending its RETR
command? What happens when you disable e-mail scanning by your
anti-virus software?

Since you might no longer have the problematic e-mail on the mail server
to test, the above are just some suggestions as to what to look at next
time.
 
Back
Top