ietf-mxcomp
[Top] [All Lists]

RE: DEPLOY: Creating bounces from forged messages

2004-08-24 16:15:00

On Tue, 2004-08-24 at 14:54, Jim Lyon wrote:
Doug Otis writes in about bounces to forged messages, making the
following points:

1. Sometimes, messages get relayed from MTA to MTA to MTA before
arriving at their ultimate destination.

2. If you relay to an MTA that refuses a message, you MUST generate a
bounce.

3. If you receive a bounce from what you regard as a reputable MTA,
you'll deliver it. 

He then asks how I think SenderID will result in fewer bounces.  Here's
how:

Most forged mail is sent by specialized spam engines (including zombie
machines) directly to the Internet-facing gateway machine of the
recipient.  Unlike most legitimate mail, it doesn't pass through an MTA
in the sender's organization.

A sending MTA is able to spoof its authorization in many ways.  One
method would be using Sender-ID's generous "open" record used by those
brave soles wanting to send mail from other points of access, while
still identifying themselves to their recipients with their well-known
mailbox address.  Perhaps they use a type of digital signature as an
assurance.  If the initial MTA is a relay into this domain, it will be
generating bounces when the recipient is invalid or when a virus is
detected by a post acceptance process.  These virus bounces often do not
have null return paths nor do they require a relay for the bounce.  

Do these relays exist? Yes.

Does Sender-ID reduce the number of such relays? No.

Does Sender-ID reduce the number of such bounces? No.

Does the mail from a spammer need to pass through several of their own
MTAs for a bounce to be created?  Absolutely not!

When the Internet-facing MTA of the recipient receives the message, it
can perform SenderID checks and refuse the message, at either MAIL
command time or end-of-data time.

As I said, there are many administratively shared MTAs where not all the
checks are made upon initial acceptance.  This fact is relied upon as a
common technique used by spammers.  Once the recipient is discovered to
be invalid, this message becomes bounced.  Sender-ID has not helped.

In either case, the receiver doesn't generate a bounce (because it's
not his responsibility) and the spam engine doesn't generate a bounce
(because there's no value to them in doing so).

You have failed to understand how SMTP is often used to relay mail. 
Sender-ID makes it _extremely_ easy to spoof sending MTA authorization. 
A single sending MTA can spoof thousands of authorizations, none of
which may be using records under their administrative control.

Even if you postulated a spam engine that generated a bounce, that
bounce would generally get rejected by the same SenderID tests.

I never suggested such nonsense.  I suggested that when some domain
decides to raise their acceptance policies beyond the norm, this will
invite use of a very common spamming technique that takes advantage of
mail relays as a back-door into these sites.  Mail relays don't go away
with Sender-ID.  The harder the site attempts to use Sender-ID to refuse
mail, the more bounce traffic they will see as a result. 

-Doug


<Prev in Thread] Current Thread [Next in Thread>