On Thu, 3 Jun 2004, Greg Connor wrote:
--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)
But while we have verified a PRA for a mail, we don't use that PRA for
_anything_. All that a spammer has to do now is to find any valid PRA for
the host his zombie is running on and he can spam to his heart's delight.
This defeats the entire purpose of SPF. What is SPF actually achieving in
this case? In the early days, there was a clear agreement:
* SPF does not stop spam.
* SPF does not solve phishing.
* SPF prevents joe-job bounces.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200406/0152.html
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
MAIL FROM was supposed to be the PRA. Otherwise we are implicitly sending
all bounces and replies to some party which, by our own terminology, is
NOT RESPONSIBLE for the mail!
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.
Bounces from forged mail was the original problem that SPF was trying to
address. Now it's not addressing any problem at all.
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.
SES only works if you're willing to prevent a given signed address from
being used for replay. This means that you have to checksum quite a lot of
data into the signature, and none of this data is guaranteed immutable. This
also breaks forwarding (Whoops, the recipient address changed), mailing
lists (Whoops, the body changed) and so forth.
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.
SRS has been an implementation barrier. We are working hard on that at the
moment.
S.
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>
-------
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
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/