Re: I found the answer to the Comcast spam block

From: *Vanguard* (no-email_at_post-reply-in-newsgroup.invalid)
Date: 03/19/04 

Date: Fri, 19 Mar 2004 00:13:30 -0600

"Robert Aldwinckle" said in
news:%23UnJcNSDEHA.3408@tk2msftngp13.phx.gbl:
> Are you using rules regarding size? I have never seen OE use the
> TOP command but I don't use rules.

Actually it was from another e-mail client whose logs are easier to read
and find where I watched the POP3 commands and noticed the immediate
server disconnect after the TOP command.

I did run a test to see the POP3 command in OE's logfile when polling
for new messages. I don't use OE for e-mail so I have no rules defined
in it for e-mail. I saw in its logfile the following (comments in
brackets):

[rx] +OK [must've been from the MAIL command]
[tx] USER <myname>
[rx] +OK
[tx] PASS <mypwd>
[rx] +OK ready
[tx] STAT
[rx] +OK 1 1114 [the test msg]
[tx] LIST
[rx] +OK 1 messages (1114) [the test msg]
[rx] 1 1114
[rx] .
[tx] RETR 1 [gets the entire test msg]
[rx] +OK
[tx] DELE 1 [got the msg, delete it off server]
[rx] +OK
[tx] QUIT
[rx] +OK <myserver>

So OE yanks the entire message; i.e., it won't just download the
headers. Although Outlook can be configured to just download headers,
that is not how I have it configured. So its log shows pretty much the
same as OE (in that Outlook is yanking the entire message) on a mail
poll:

<rx> +OK [response from MAIL command]
[tx] USER <myname>
<rx> +OK
[tx] PASS <mypwd>
<rx> +OK ready
[tx] STAT
<rx> +OK 1 1114 [pending test e-mail]
[tx] UIDL
<rx> +OK 1 messages (1114) [test e-mail]
<rx> 1 20040319053511s130092mcbe0000c4
<rx> .
[tx] LIST
<rx> +OK 1 messages (1114) [for test e-mail]
<rx> 1 1114
<rx> .
[tx] RETR 1 [yanks entire message]
<rx> +OK
[tx] DELE 1 [delete it from server]
<rx> +OK
[tx] QUIT
<rx> +OK <myserver>

Although there is no TOP command, their POP3 server supports the
optional UIDL command issued by Outlook which would be a strong
indicator that they would also support the TOP command. From the e-mail
monitor where I was first looking at the POP3 command (Magic Mail
Monitor; mmm3.sourceforge.net), its log showed:

Rcvd: +OK [from MAIL command]
Sent: USER <myname>
Rcvd: +OK
Sent: PASS <mypwd>
Rcvd: +OK ready
Sent: UIDL [this is one of those optional commands]
Rcvd: +OK 1 messages (1118)
Rcvd: 1 20040319054913s13008v7g2e0000c5
Rcvd: .
Sent: LIST
Rcvd: +OK 1 messages (1118)
Rcvd: 1 1886
Rcvd: .
Sent: TOP 1 0 [show first zero lines of msg #1 - just headers]
Rcvd: +OK Message follows
[this is where the server disconnects for the bad e-mail]

I could configure the e-mail monitor to yank the first, say, 5 lines of
each message but I don't want to waste the time in a monitor program.
Although zero lines of the body get pulled, the headers still do get
pulled. This lets me run rules in Magic against the headers. Notice
the "+OK" status gets returned from the TOP command. If the POP3 server
didn't support this command, it is supposed to return "-ERR". When the
corrupted e-mail was in my Inbox, the server disconnected right after
issuing the "+OK" status. It said okay and then went away, so something
really wasn't okay. My client never got to issue the next command which
would have been QUIT because the server already disconnected. The above
could be repeated on every mail poll when the corruptive e-mail was in
my Inbox. Once it got deleted, the "+OK" status from the server gets
followed by several Rcvd lines, one for each header in the message, the
"." line to denote end of data, and then my client issues the QUIT
command and the session ends normally.

When the tech had me click "report this as spam" button while looking at
my Inbox using their webmail interface, I figured I could still do some
investigating afterward. However, their spam reporting procedure then
deleted the message from my Inbox (and it wasn't in the Trash folder,
either). So it was too late for me to enable transport logging in OE
and Outlook to see what it would do. I suspect it got to and completed
the LIST command and then the server aborted on the RETR command
because, like the TOP command, the POP3 server would then have to start
sending the contents of the message (which includes the headers). So
whether it was the TOP or RETR command, the POP3 server puked when
trying to spew the contents of corruptive e-mail (and just for the
headers in the case of the TOP command) and did an immediate disconnect.

If there were other messages in my Inbox besides the corruptive one,
they could be yanked successully (I don't know if their order just
happened to let them get yanked first before trying the corruptive
e-mail). But Outlook and Magic would still report errors due to the
nongraceful server disconnect when it got to the corruptive e-mail.

The TOP command is an optional command as per section 7 of RFC 1939 for
POP3. However, the mail server is expected to report an error status
code ("-ERR") rather than simply abort and disconnect. Also, the
logfile showed the TOP command was issued and the mail server responded
"+OK" so the Comcast POP3 mail server *DOES* support the TOP command
(but apparently has a problem with corrupted messages or with these
trojan-like e-mails). After getting the "+OK" status (which I did get),
the mail server is supposed to send a list of the headers for each
e-mail. That's where Comcast's mail server decided to disconnect from
me (and so my e-mail monitor client would report the error). In my
case, the command was "TOP 1 0" which meant it was trying to retrieve
the first 0 lines (the e-mail client I used was only trying to list
the headers) of the first message item (because the only e-mail in my
Inbox at the time was the corruptive message).

>From what I can see returned by the POP3 server in response to a TOP
command, it doesn't just send a subset of the headers, like From, Date,
Subject, and Reply-To. *ALL* the headers are returned for a TOP
command. Maybe Comcast's POP3 can't handle more than some maximum
number or aggregate length for the headers. I know a lot of spammers
are trying to bias Bayesian filters by sliding in strings in the headers
so maybe some escape code, upper ASCII or Unicode characters, or a
particular string in the headers is causing Comcast's POP3 server to get
hung in dumping out the list of header in response to a TOP command.

Whether for the RETR or optional TOP command, the corruptive e-mail
would cause the POP3 server to abort and disconnect whenever it had to
download the headers of that message. Unfortunately, I no longer have
that bad message to continue playing with the e-mail clients and server.
Now I have to wait another couple weeks for it to show up again.