|
Re: SUBMITTER is a bad idea
2004-06-03 16:47:36
--spf(_at_)anarres(_dot_)org wrote:
My thesis is that SUBMITTER/RFROM/DAVE is a bad idea.
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)
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.
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.
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). 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.
The possible responses I expect from the proponents of SUBMITTER are:
"But we send bounces to SUBMITTER".
- In this case, MAIL FROM is redundant, and we are proposing
rewriting SMTP for no purpose. The current system just puts the
PRA in MAIL FROM. This should continue.
"We can verify MAIL FROM as well."
- Differently to the verification of SUBMITTER? How?
The effect of introduing SUBMITTER is to entirely defeat the original
purpose of SPF, that is, to permit spammers to send their bounces to
arbitrary locations.
I appreciate the political constraints introduced by attempting to
cooperate with uncooperative parties with differing agendas to that of
SPF, but what is being achieved here is a total destruction of the
utility of the protocol.
SUBMITTER is therefore bad and should be excluded from any future
protocol.
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
-------
Sender Policy Framework: http://spf.pobox.com/
The Inbox Event at the Marriott San Jose features SPF.
June 2: Email Accountability Symposium (free)
June 3: SPF Strategy BOF (free) where industry will coordinate
deployment timeline Times: 6:30pm - 8pm, both sessions.
http://www.inboxevent.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription, please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
|
|