OT: Spoofed Email

[* * Chas]

The majority of Spam that I receive has been sent to a spoofed Email
address. My Email addresses are not even listed.

This happens with Comcast, AT&T and AOL (which I only use for Email).

Any idea how these misaddresed Emails get through the ISPs' servers?

I have safe ways of dealing with these without opening them but it's a
pain in the butt deleting them everyday.


Chas.

 

[Beauregard T. Shagnasty]

The majority of Spam that I receive has been sent to a spoofed Email
address. My Email addresses are not even listed.

The mail would not get to you if you weren't addressed.

http://www.jamesshuggins.com/h/web1/bcc_field.htm

Frequently, the one address you may see in the TO: field does belong to
one of the spammer's victims. So could the FROM: address.

This happens with Comcast, AT&T and AOL (which I only use for Email).

Doesn't matter who your ISP or email host is.

Any idea how these misaddresed Emails get through the ISPs' servers?

See above.

I have safe ways of dealing with these without opening them but it's
a pain in the butt deleting them everyday.

That is true.

 

[me]

The majority of Spam that I receive has been sent to a
spoofed Email address. My Email addresses are not even
listed.

This happens with Comcast, AT&T and AOL (which I only use
for Email).

Any idea how these misaddresed Emails get through the ISPs'
servers?

I have safe ways of dealing with these without opening them
but it's a pain in the butt deleting them everyday.


Chas.

Fairly simple at
http://www.ietf.org/rfc/rfc2822.txt
Look under
"3.6.3. Destination address fields"
and related "Security Considerations"

J

 

[* * Chas]

The mail would not get to you if you weren't addressed.

http://www.jamesshuggins.com/h/web1/bcc_field.htm

Frequently, the one address you may see in the TO: field does belong to
one of the spammer's victims. So could the FROM: address.
Email).

Doesn't matter who your ISP or email host is.


See above.


That is true.

Good link, thanks for the response.

I've just been attributing the problem to faulty servers that let
misaddresed messages slip through.

In looking at the properties of the offending messages, via OE,
MailWasher Pro, Thunderbird and my web mail sites, I've found that my
address sometimes shows up in the cc section but I haven't seen any BCC
section of these messages. Does this portion get stripped off of the
message?

Chas.

 

[* * Chas]

Fairly simple at
http://www.ietf.org/rfc/rfc2822.txt
Look under
"3.6.3. Destination address fields"
and related "Security Considerations"

Thanks for the response and link.

In looking at the properties of some of these messages, I found that my
address was sometimes showing in the cc field but I haven't found any
messages with a bcc field.

So, my question is still, how do I get Emails that don't contain any
trace of my addresses?

How do they slip through ISP mail servers and why don't they stop these
kinds of messages?

Chas.

 

[Andy Walker]

So, my question is still, how do I get Emails that don't contain any
trace of my addresses?

RFC 822
4.5.3. BCC / RESENT-BCC

This field contains the identity of additional recipients of
the message. The contents of this field are not included in
copies of the message sent to the primary and secondary reci-
pients. Some systems may choose to include the text of the
"Bcc" field only in the author(s)'s copy, while others may
also include it in the text sent to all those indicated in the
"Bcc" list.
http://www.faqs.org/rfcs/rfc822.html

How do they slip through ISP mail servers and why don't they stop these
kinds of messages?

Because Simple Mail Transport Protocol is designed to allow them to be
delivered to the address in the bcc header.

 

[Beauregard T. Shagnasty]

* * Chas wrote:

In looking at the properties of some of these messages, I found that
my address was sometimes showing in the cc field but I haven't found
any messages with a bcc field.

And you never will. That is why the field is called "Blind." If a mail
server started including the BCC in the headers, I would dump that
service immediately.

So, my question is still, how do I get Emails that don't contain any
trace of my addresses?

"You are there." You just can't see it - by design. Your ISP sees it,
and delivers it.

How do they slip through ISP mail servers and why don't they stop
these kinds of messages?

If the ISP failed to send me email where I am in the BCC, I would ..
again .. drop that service immediately.

Spammers are NOT the only people who use BCC. I regularly send email to
a couple hundred club members, and all of their addresses are in the
BCC, so as to protect their privacy. And to keep their addresses off the
computers of n00bs with viruses and worms that could harvest them.

One intent of the BCC is to send mail to multiple people who don't know
each other, for the above stated reason.

 

[Nick FitzGerald]

"* * Chas" to "Beauregard T. Shagnasty":

Good link, thanks for the response.

Well, it may have seemed good to you, BUT it was not actually very helpful, as
it hasn't helped you actually understand what is going on...

I've just been attributing the problem to faulty servers that let
misaddresed messages slip through.

Nope -- all the servers in the delivery chain are (pretty much) just
doing what the RFCs require them to do so SMTP Email works.

In looking at the properties of the offending messages, via OE,
MailWasher Pro, Thunderbird and my web mail sites, I've found that my
address sometimes shows up in the cc section but I haven't seen any BCC
section of these messages. Does this portion get stripped off of the
message?

Look, BCC is a red-herring, both here and in the other fork of this thread.
The RFCs _are_ the place to go to work out what is really happening, but the
poster who sent you to look at the RFCs sent you to the wrong place...

RFC 2822 section 3.6.7, and especially its discussion of the "Return-Path:"
field, is the only stuff of great relevance in RFC 2822. More important is
RFC 2821 as that deals with the mechanics of message _delivery_. (Note that,
depending on your mail client, you may not even be able to display the _full_
headers as described in RFC 2822. Also note that, depending on your Email
client or even server, you may not see a "Return-Path:" header but instead a
"From " header and in the past (I don't recall the MUA but think it was on a
VAX running VMS) I once even saw "Received-From:" instead of "Return-Path:".)

Anyway, the reason "your" spam is arriving despite apparently not having your
address in any of the (obvious) addressing headers is because of the way that
RFC 2821 defines delivery of SMTP Email. If you don't want to read the whole
RFC (probably advisable!) start with section 3.3 and pay special attention to
the relationship between the "MAIL FROM:" and "RCPT TO:" command and the
_actual message including all its standard, invariant (sending MUA-specified)
headers_. (A hint: the latter are all contained within the "DATA" part of the
transmission and thus have a _purely arbitrary_ relationship with the "MAIL
FROM:" and "RCPT TO:" delivery protocol commands.)

This feature is what allows various kinds of spoofing, allows for BCC
functionality, makes running mailing lists and such much easier, and probably
many other good features.

I hope this helps...

 

[* * Chas]

"* * Chas" to "Beauregard T. Shagnasty":



Well, it may have seemed good to you, BUT it was not actually very helpful, as
it hasn't helped you actually understand what is going on...


Nope -- all the servers in the delivery chain are (pretty much) just
doing what the RFCs require them to do so SMTP Email works.


Look, BCC is a red-herring, both here and in the other fork of this thread.
The RFCs _are_ the place to go to work out what is really happening, but the
poster who sent you to look at the RFCs sent you to the wrong place...

RFC 2822 section 3.6.7, and especially its discussion of the "Return-Path:"
field, is the only stuff of great relevance in RFC 2822. More important is
RFC 2821 as that deals with the mechanics of message _delivery_. (Note that,
depending on your mail client, you may not even be able to display the _full_
headers as described in RFC 2822. Also note that, depending on your Email
client or even server, you may not see a "Return-Path:" header but instead a
"From " header and in the past (I don't recall the MUA but think it was on a
VAX running VMS) I once even saw "Received-From:" instead of "Return-Path:".)

Anyway, the reason "your" spam is arriving despite apparently not having your
address in any of the (obvious) addressing headers is because of the way that
RFC 2821 defines delivery of SMTP Email. If you don't want to read the whole
RFC (probably advisable!) start with section 3.3 and pay special attention to
the relationship between the "MAIL FROM:" and "RCPT TO:" command and the
_actual message including all its standard, invariant (sending MUA-specified)
headers_. (A hint: the latter are all contained within the "DATA" part of the
transmission and thus have a _purely arbitrary_ relationship with the "MAIL
FROM:" and "RCPT TO:" delivery protocol commands.)

This feature is what allows various kinds of spoofing, allows for BCC
functionality, makes running mailing lists and such much easier, and probably
many other good features.

I hope this helps...

Thanks Nick,

I've been trying to understand how Email works to see if there is
anything that I could do to stop the flow of junk before it gets
downloaded. MY ISPs are no help.

I avoided using BCC myself after several people I know sent out
confidential business information to unauthorized recipients. Very
embarrassing for all involved.

I use older versions of AOL for my spam catcher Email. I have all the
people who send me large junk files (jokes, pictures etc.) use one of my
AOL addresses. I can delete them w/o having to DL the messages and I
periodically delete the accounts and set up new ones.

Chas.