spf-discuss
[Top] [All Lists]

RE: SUBMITTER is a bad idea

2004-06-03 18:49:17
From: Greg Connor
Sent: Thursday, June 03, 2004 6:48 PM


--spf(_at_)anarres(_dot_)org wrote:

My thesis is that SUBMITTER/RFROM/DAVE is a bad idea.

I agree with Shevek on this, assuming that we only validate SUBMITTER and
the destination gateway MTA cannot validate MAIL FROM: in the presence of
forwards.  I personally favor the use of the deprecated source route format
for MAIL FROM: instead of SUBMITTER, but this is just a different way to
transmit the same information.

There is still the valid dichotomy that Shevek brings up concerning the two
addresses that must be solved if we are to accomplish the original goals of
SPF.


Spammers are currently saving considerable bandwidth by providing false
return paths in mail. SPF was originally designed to prevent mailers
from accepting mails with false return paths, and hence to prevent users
recieving bounces from mails they didn't send.

There is a suggestion to extend the mail protocol to have both
SUBMITTER,
the "responsible address" or PRA, and MAIL FROM, the "origial source" of
the message. The PRA is validated according to SPF rules. The MAIL FROM
recieves bounces.

But suddenly we are verifying one address and sending bounces
to another!


I understand and appreciate the concerns here.  The concerns that
RFROM/SUBMITTER is trying to address are,

 1. MAIL FROM validation depends on SRS, and forwarders don't
like SRS.  We
sidestep some forwarder problems by validating a header they can prepend
easily (and many already do).  The last hop is identified by the
Resent-Sender, Resent-From, Delivered-To, Sender, and From, according to
the first listed one that appears.  This "last hop injection point" or
"last forwarder" is called PRA (Purported Responsible Address)
and has the
domain part similar to what we would have seen in SRS.  The
assumption here
is that, for purposes of determining a mail Legit or NotLegit,
PRA and MAIL
FROM are probably similar in effectiveness.  We don't have to deal with
SRS, but we lose control over bounces being sent to us (for now--
see below)

I don't necessarily agree that PRA and MAIL FROM: are equally effective.  As
you note, this also causes forged bounces to be directed towards innocent
domains.  We can deflect those with SES, but all this network traffic could
have been avoided had we rejected the message earlier.  I believe we can
solve this problem.  See proposal below.



 2. The real work being done by the New SPF is to validate the
PRA from the
headers, but we don't want to get all the way to DATA to see the
PRA, so we
add an optimization to SMTP to add SUBMITTER to the MAIL command.  This
gives a sneak-preview of the PRA address we will find in the headers.  If
the headers turn out to have a different PRA, the message is
rejected.  If
the SUBMITTER is given, the SPF result of checking submitter MUST
be PASS,
an unknown or fail is not accepted.  The main point is to get
something we
can validate before DATA, so that we save bandwidth and can reject forged
mail.

Bounces from forged mail is still a problem, for now.  There are a couple
of wishes that need to come true for bounces from forged mail to be
addressed.

 3. Eventually when enough forwarders are using SUBMITTER, key
players will
start using MAIL FROM to reject, if SUBMITTER is not present.  The
assumption is that if SUBMITTER is not given, the MAIL FROM entity IS the
PRA.  If you want to forward mail on behalf of someone else you need to
either rewrite MAIL FROM or add SUBMITTER.  This gives us the bandwidth
savings of being able to reject forged mail before the DATA
phase, finally.

The key thing to realize here is that the first hop validates MAIL FROM:
using SPF tests, _iff_ originating gateway MTA's doesn't include SUBMITTER.
Subsequent hops validate the SUBMITTER information, but assume the MAIL FROM
: was validated by someone prior.  This allows someone to provide accurate
SUBMITTER information with forged MAIL FROM: and it will pass in the current
system.  SPF has always been a hop-to-hop validation scheme and requires the
end user to trust that the first forwarder did their due diligence on the
incoming mail.  As long as the first forwarder does their job, the end
result is a workable validation scheme.  Since the average user has no way
of knowing what their forwarder does with incoming mail, and reputation
systems are still pipe dreams, this has been a problem since day one of SPF
and remains a problem.  SRS or the lack of it have not changed this
situation at all.  It has always been hop-to-hop validation with inheritance
of trust for the originating hop.

There are really only a few solutions to this.  If the forwarders are all as
diligent SPF checkers on incoming mail as we would be, there is no problem.
Unfortunately, we can't assess that.  A reputation system would help, but
that does not exist.  Under these constraints, end-to-end validation is the
only way to validate MAIL FROM: with certainty.  This is a bitter pill.

The DK proposal does this, but puts the burden on the recipient and has a
lot of potential for breakage of non-conforming systems.  It appears to be
all-or-nothing and that does not bode well for adoption.  S/MIME and PGP are
great, but they don't permit rejection at the MTA before DATA.  SES can be
used for this, but CBV's have proven to be unpalatable to many.

Thinking a little outside the box and taking a few risks, here is one
possible solution:

1) Senders SES sign all outgoing mail.

2) Sender's DNS SHOULD be able to validate SES signatures via DNS query.

3) Each recipient MUST do the following:

a) If SUBMITTER (or its source route equivalent) exists, do an SPF check to
validate the SMTP-client.  If the result is other than PASS, reject the
message.

b) If there is no SUBMITTER, do an SPF check on MAIL FROM: to validate the
SMTP-client.  If the result is other than PASS, reject the message.


4) Each recipient SHOULD do, and the destination gateway MTA MUST do the
following:

a) If there was a SUBMITTER, test the MAIL FROM: via DNS query.  If the
result is other than PASS, reject the message.

b) Proceed to DATA.  If there is a Sender: header, reject the message if
(MAIL FROM: != Sender:).  If there is no Sender: header, reject the message
if (MAIL FROM: != From:).  If there are multiple From: addresses and no
Sender: address, reject the message as malformed and unverifiable.
Otherwise, accept the message.


This requires some DNS modification, but the system has some very desirable
properties:

i) The validity of MAIL FROM: can be checked at every hop and will _at
least_ be checked at the destination gateway MTA.

ii) Because of i), forgers can create a message with a valid SUBMITTER and a
forged MAIL FROM:, but it will be rejected at the destination.

iii) Every mailer in the path still must be a designated sender for their
domain.

iv) Since we validate MAIL FROM:, and that address must appear in
From:/Sender:, the sender address the user sees is validated.

v) Validation of the SES signed MAIL FROM: occurs at the sender's
nameserver.  The network bandwidth utilized is minimal since it is a short
DNS query with an even shorter return result.



 4. It is possible to send bounces to a third party, using SUBMITTER, if
you are determined to do so.  The spammer posing as a forwarder must give
valid credentials for SUBMITTER to do this.  In other words, a PASS with
the SUBMITTER value trumps MAIL FROM.  If SUBMITTER is given at all, the
result MUST be pass.  It is possible to give MAIL FROM: <innocent>
SUBMITTER=<spammer>, and in that case, bounces will go to the innocent.
This is a shift from SRS.  I believe 1. that having a SUBMITTER
value that
is guaranteed to Pass is good, even if we may be vulnerable to
bouncing to
someone innocent, and 2. that there is no advantage to spammers
to do so...
they are not getting their message in front of new eyeballs
inaccessible to
them before, so there is no reason for them to go to the effort of
redirecting their bounces (and exposing their identity to do so) if it
doesn't buy them anything.

 5. One of the topics discussed at MARID is that SES can be employed to
stop bounces, and that can be done unilaterally by a sender, without
waiting for the rest of the world to be SPF compliant.  Some
domain owners
may just live with the bounces for now, and some who really want to be
proactive will put in SES to protect themselves from blowback.  SES is a
big stick, but isn't much harder to implement than SRS, and gives you
positive results immediately, instead of waiting for everyone else.

It seems shortsighted if we don't require this.  Even if we don't do the
special DNS validation, this still gets the sender huge benefits.  Why not
just require this and build it into the implementation?  If it's part of the
reference implementations, we all benefit.



Now.. I think Shevek has a good point, that there is still a
possibility of
a vulnerability here, and SES is not the only answer (for the
same reasons
people didn't like SRS).

I disagree with that assessment.  SRS required all forwarders to do
something quite different and subsequent systems to understand it.  SES is
implemented at the source end and still works regardless of what others do.

The New SPF can be exploited if someone is
malicious and wants to do so.  I think we need to be careful to make sure
that there is no advantage to the spammer for doing so, and hopefully a
disadvantage, but if they want to expose their own domain they can still
game the system.

One way for a hostile domain to exploit the New SPF is to give correct
SUBMITTER information but forged MAIL FROM:.  This will pass all SPF checks
on it's way to the destination.  The forger did expose their domain but it
is buried in the Received: headers.

--

Seth Goodman


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