spf-discuss
[Top] [All Lists]

RE: Forking SPF into The New SPF and SPF1

2004-06-09 15:28:00
From: Stuart D. Gathman
Sent: Wednesday, June 09, 2004 4:20 PM


On Wed, 9 Jun 2004, Seth Goodman wrote:

I like the idea of calling them "layers". I will be able to keep the
RFC2821 layer (spf-v1) and anybody willing to put XML parsers
into their
MTAs can use the RFC2822 layer (spf-v2 + cid).

I can appreciate the benefit of the two layers.  However,
requiring XML to
do the 2822 checks may well doom it to failure.  I think you
phrased it well
when you said, "anybody willing to put XML parsers into their MTAs", and
that is not a very large group.  I would like to see 2822
checks happen, but
think that relegating them to XML will prevent deployment.  If
you really
want 2822 checks to happen, I would suggest not requiring XML
for them.  If
you really _don't_ want 2822 checks to happen, then please make
an argument
for that, but don't put an albatross around its neck in the
form of XML that
will kill it indirectly.

My theory is that the XML 2822 checks can happen outside the MTA.  WAIT!
Before anybody screams about bogus bounces to innocent domains,
suppose that layer 1 checks are a requirement for bouncing or dropping
a message that fails layer 2 checks after accepting the message.
Wouldn't layer 1 still prevent sending all the bogus bounces to innocent
domains?

Almost, but not completely.  You be the judge as whether it is good enough
based on the following:

assume spammer.com is a real domain with an SPF record,

MAIL FROM:<victim(_at_)domain1> SUBMITTER:<outgoing(_at_)spammer(_dot_)com>
RCPT TO:<non-existent-user(_at_)domain2>

This mail will pass SPF as received by domain2, but the original sender,
victim(_at_)domain1 is a forgery.  All the variations of SPF are susceptible to
this attack in one form or another.  The problem is that SPF, in all of its
variations, only validates the original sender at the first hop.  For every
hop after that, you have to trust that every one in the message chain was
honest, but you cannot determine that.  The spammer ultimately gives up his
identity by doing this, but a disposable domain per spam run is not that big
a hurdle.

Unless you are talking to the originator, you can't tell if the forwarder
you have on the line is legitimate or a spammer who has forged the
originating address.  In the case where there is no forwarder, your
assertion is certainly true and it is safe to send bounces to the MAIL FROM:
address after the end of DATA.

--

Seth Goodman