Subject: RE: DEPLOY: Creating bounces from forged messages

From: "Jim Lyon" <[email-masked]>
Date: Tue, 24 Aug 2004 14:54:54 -0700

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.

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.  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).  Even if you postulated a spam engine that generated a
bounce, that bounce would generally get rejected by the same SenderID
tests.

That's how.

-- Jim Lyon

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Aug 2004 16:15:04 -0700

On Tue, 2004-08-24 at 14:54, Jim Lyon wrote:
> machines) directly to the Internet-facing gateway machine of the

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
> 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