ietf-mxcomp
[Top] [All Lists]

RE: Point of Order: Incomplete, flawed response to MARID WG Charter

2004-08-19 21:33:10

On Fri, 20 Aug 2004, Roy Badami wrote:

"terry" ==   <terry(_at_)ashtonwoodshomes(_dot_)com> writes:

    terry> I agree to move on, but 1 quick note re adoption, those
    terry> that implement spf will suffer significantly less
    terry> backscatter, because backscatter from the wrong mta will be
    terry> rejected.

Regards to Terry point: Backscatter from the MTA would not be rejected
since it is a message _to_ the backscatter victim _from_ the MTA. Even if
both MTAs participate in SPF, the SPF check should find the MTA's mailer
delivery system address to be authorized to that MTA.

I think you're mistaken.  Backscatter generally comes from legitimate
MTAs (as you point out, spammers/viruses themselves don't bother to
generate bounces).

When a forged message transits a legitimate MTA, and that MTA is
unable to deliver (receives a 5xx for whatever reason) it generates a
bounce.  This bounce is from <>, so SPF will check the HELO.  Being a
legitimate MTA, it includes its legitimate name in the HELO string.
The bounce will pass an SPF check.

Exactly right.  It is probably from postmaster, but could be from <>.

Every user everywhere is the customer of an ISP or a 
company with an MTA.  _All_ spam is sent by customers of someone.  So 
_all_ abuse has a relay that will just relay email. An inside "closed" 
relay is "open" to anyone inside the network.   

If we assume that anti-trust laws will require ISPs to permit other ISPs
to provide services to unbundled email, then SPF will have no effect at
all: Ever.  If that isn't the case, then _every_ forged email results in
backscatter:  _All_, _100%_

SPF and many other schemes assumes that the abusers won't alter their
habits.  The goal of the abuser is to abuse.  Of course they are going to
alter their sending habits.  This has happened again and again.

I say again:

SPF does not prevent backscatter (at least not unless every MTA on the
planet adopts it).

The backscatter issue does not consitute an argument against
proceeding with the work on Sender ID and CSV (the WG's current work
items) though both will result in backscatter to some extent.

    -roy





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