Re: blank email in OE

• Previous message: Hairy One Kenobi: "Re: blank email in OE"
• In reply to: RB: "Re: blank email in OE"
• Next in thread: RB: "Re: blank email in OE"
• Reply: RB: "Re: blank email in OE"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Mon, 06 Dec 2004 13:40:04 -0600

In article <PBIsd.102908$IQ.49687@bignews6.bellsouth.net>, RB wrote:

>Here's the header on the only one I have in my pc right now. It is shorter
>than many, and doesn't show a "TO:" email address in there:

Mail is sent from one computer to another using the SMTP (Simple Mail
Transport Protocol). The sending computer starts the transaction by
saying hello, and the receiving computer returning the greeting while
looking up the address. Here, the conversation went:

  Hello imf08aec.mail.bellsouth.net, this is
    commons10k2.mo24.107.103.84.charter-stl.com

  Hello commons10k2.mo24.107.103.84.charter-stl.com, pleased to meet you.
    (remote host was at 24.107.103.84, at Sat, 4 Dec 2004 10:37:22 -0500)

That creates the first (and in this case, only) Received: line. Some
mail servers carry this one step further, and look up the address that belongs
to the remote hostname, and put that in the header too.

  Mail from <vywlldysaws@mailfreeway.com>

  Sender OK

That created the "Return-Path:" line - it's called the 'Envelope Sender'

  Deliver to <Mumble>

  Recipient OK

  Deliver to <Mumble2>

  Recipient OK

This information does NOT make it into the mail - this is the 'Envelope
Recipient'. Now, I know there were two OR MORE _valid_ recipients because
this information was not put into the Received: header (mail to a single
recipient would have your address included between the 'SMTP id' and
date). The above are the "Envelope" headers, put there by the receiving
server. You can probably trust the headers put there by your mail server
(or the mail server of your ISP).

  DATA

  Start mail input; end with <CRLF>.<CRLF>

This kicks the mail servers into the transfer mode - everything sent
from now on is put into the delivered mail following the top 'Received:'
line. Briefly, this is the rest of the headers, a blank line, then the
"body" of the mail. This mode ends when the sender sends a line of text
that ONLY contains a dot. At that point, the receiving server sends a "OK,
I got it", or an error message, and this transaction ends.

Note: Mail may have multiple "Received:" headers. The mail may have been
_forwarded_ from one server to another, and each tacks on it's Received
headers. At the following stage, these follows the DATA command, and may
not be trustworthy. (Did the mail "originate in Los Angeles", get sent
to a server in "Paris", but get delivered to your ISP from a server in
"Hong Kong"?? Wait a minute - how did it get from Paris to Hong Kong, and
why did it go to either place, when you are in San Diego? This doesn't
smell good!!!). Another thing to watch for is mail that claims to have
originated at your ISP (or even from you), but is being delivered to it
from some server in South Korea or Finland. Do you _really_ think mail
would be sent from here, to there, and back again? Why?

Notice that the 'To:', 'From:', 'Subject:', Date:" and all the other
headers are internal to the mail - AND IN NO WAY SHOULD BE TRUSTED.
See RFC2821 and RFC2822 (replaces RFC821 and RFC822) for more details.
See also http://www.stopspam.org/email/headers.html

OK, now that we got that out of the way - what's with this mail? The
'Return-Path:' is useless unless your mail server is one of the rare ones
that only accepts envelope senders that match the Received: line - something
that rarely works in practice.

Second - the mail was sent from commons10k2.mo24.107.103.84.charter-stl.com
which looks to be a cable modem in Eastern Missouri. The probability says
this is a zombie - some home user who can't be bothered with anti-virus,
anti-trojan, anti-anything, and has it set to automatically click 'OK,
go ahead and install this virus' (because reading all of those messages
and moving the mouse to click the 'OK' is to hard) and as a result, the
system is 0wn3d. It's a pity, but we are not allowed to shoot such computer
owners, and smash their computers to bits - but what can I say?

Third - I'd suggest that the mail server on the zombie crashed, because it
didn't send a 'Message-Id:' or 'Date:' header (both of those were inserted
by the bellsouth mail server because they were required, but missing). You
can see this because the data is the same as that in the Received: header.

Finally - sent from a dynamic address - mail administrators with clue (and
that excludes Bellsouth, SWBell, Pacific Bell, Ameritech, and other members
of SBC) are often refusing to accept mail from them because it's almost
always spam. Some ISPs are finally getting around to blocking any outbound
packets being sent to mail servers OTHER THAN THEIR OWN.

        Old guy

• Previous message: Hairy One Kenobi: "Re: blank email in OE"
• In reply to: RB: "Re: blank email in OE"
• Next in thread: RB: "Re: blank email in OE"
• Reply: RB: "Re: blank email in OE"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]