«

In article <PBIsd.102908$>, on Sun, 5 Dec 2004 12:40:48 -0600, "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:
|
| Return-Path: <>
| Received: from commons10k2.mo24.107.103.84.charter-stl.com
| ([24.107.103.84]) by imf08aec.mail.bellsouth.net
| (InterMail vM.5.01.06.11 201-253-122-130-111-20040605) with SMTP
| id
| <20041204153722.TUJH3826.imf08aec.mail.bellsouth.n 24.107.10
| 3.84.charter-stl.com>;
| Sat, 4 Dec 2004 10:37:22 -0500
| X-Message-Info: C/z[1
| Message-Id:
| <20041204153722.TUJH3826.imf08aec.mail.bellsouth.n 24.107.10
| 3.84.charter-stl.com>
| Date: Sat, 4 Dec 2004 10:37:22 -0500

I've had similar mails and assumed they were sent by spammers who were
even more stupid than normal and unable to configure their spamware properly.

No subject, and no contents. How do they expect anyone to contact them?

Your address would have been in a "Bcc:" header (probably together with
many other spammer victims email addresses). This gets removed during the mail
routing by the sending server so you don't see everyone elses email addresses.

Some isp mailer servers will add an extra header called something like
"X-Envelope-To:" which will then show what email address actually recieved
the mail and will correspond your email address portion of the "Bcc:" header.

<davidp />

--
David Postill

"RB" <> wrote in message
news:YAusd.40055$. ..
> I'll ask this one here, as I'm not sure there's a better place to direct
it.
>
> At least once and day, I receive an email with a totally blank line in the
> address window. There is the usual little envelope over on the left, but
> the rest of the line is blank.

It's a standard probe - someone performing a dictionary "attack" (hardly
worthy of the word!) on your ISP's email server.

I find they usually come on bunches of four or five on my work server, as
I'm in several groups that are accessible from the outside world.

HTH

Hairy One Kenobi

Disclaimer: the opinions expressed in this opinion do not necessarily
reflect the opinions of the highly-opinionated person expressing the opinion
in the first place. So there!

In article <PBIsd.102908$>, 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 <>

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

Moe Trin wrote a lengthy explanation of what was in the header of the blank
email I received.

Thanks. That was fascinating and enlightening. If I understood it right,
we really don't know much about what was going on.

But, it's interesting. Someone said it's probably a phishing thing where
simply opening the email sends a confirmation that it reached a valid email
address for puposes of further mischief of some sort. Sounds logical.

In article <etttd.40445$>, RB wrote:

>Moe Trin wrote a lengthy explanation of what was in the header of the blank
>email I received.

Actually, that was drastically shortened. The two RFCs (2821 and 2822)
that are the controlling documents for basic mail total 7300 lines of text
(79 and 51 pages when printed).

>Thanks. That was fascinating and enlightening. If I understood it right,
>we really don't know much about what was going on.

Other than you got a partial mail delivered from some zombie on charter
net - no, there isn't much you can positively state. Opinions, of course,
are another thing.

>But, it's interesting. Someone said it's probably a phishing thing where
>simply opening the email sends a confirmation that it reached a valid email
>address for puposes of further mischief of some sort. Sounds logical.

That would be mail with a URL inside (often a unique 'page' with a coded
number to the right of the slash at the end of the hostname), and the
victim using a web browser to read the mail that is configured to auto-
open any URL. Outlook Express is notorious for this, but others can be
configured that way. What that method does is not only confirms that the
address is good, but also that the mail is being read by someone who's
browser is wide open and begging to be exploited. Smart people don't
accept mail in HTML (that's for web pages, not mail or news), and some
don't even accept mail unless it is ONLY plain ASCII text. I don't know
about you, but I really don't give a f*ck about animation or color or
special fonts in my mail.

However, the mere acceptance by your (ISP's) mail server usually means
that the address is good. Remember, part of the SMTP dialog between
the sending and receiving mail server went:

] Deliver to <Mumble>
]
] Recipient OK

If <Mumble> were not a valid address, the dialog would be

Deliver to <Mumble>

Requested action not taken: mailbox unavailable

The program on the sender merely has to note which response it gets for
which name it tried. If the receiving server has the log level turned
up, this would show in the SMTP log, but normally this is not the case
because of the huge number of mails received. One of my ISPs tells me
they see 300,000 mails a day on average - that's 3.5 mails per second.
They believe that at least 98 percent of that is spam. And they are a
small family-owned ISP with less than a thousand customers total.

Old guy