From: Dick St.Peters [mailto:stpeters(_at_)NetHeaven(_dot_)com]
Sent: Friday, August 26, 2005 5:10 PM
<...>
If SPF really takes root, forwarding without sender rewriting will
indeed die.
Only if SRS is universally adopted, a very unlikely outcome, IMHO.
However, as SPF alone assures only the authenticity of an
envelope address few users care about, I predict that SPF's future is
dependent on other things also taking root.
Users may not care about the return-path, but mail system operators do.
First of all, it tells you that if you accept a message that passes SPF for
a given return-path, and you cannot achieve final deliver for some reason,
you can send a bounce without abusing innocent bystanders. Return-path
validation _is_ important for SMTP, whether end users know that or not.
In a fully SPF'd world, a forwarder won't accept mail unless is passes
SPF muster, and by rewriting the sender the forwarder makes the next
hop pass SPF. This is SPF authenticating the path without directly
addressing the authenticity of the mail itself. Illicit mail isn't
prevented, but it is made traceable.
Traceable by whom and how? Every forwarder in the path would have to
maintain complete logs, and be willing to grep them and divulge the
information to you on demand for this claim to be true. Unless you are a
large organization, I doubt that already overworked abuse teams at
forwarders would agree to spend time on this. Since some forwarders may
decide to whitelist certain senders, there is no assurance that SPF checks
were even done on all the mail. IMHO, the fully SPF'd world you describe is
a pipe dream and is the biggest difficulty with SRS.
For any protocol to be successful, it has to work at levels of adoption we
are likely to see in the foreseeable future. I disagree that SRS will see
the necessary threshold of adoption in any reasonable time frame,, which in
turn will prevent senders from publishing -all. Right now, even if you only
send through MTA's that enforce submission rights, you cannot publish -all
as you can't control the forwarding arrangements of your recipients. In
many cases, the recipients will neither be willing to change their
forwarding arrangements nor coerce their SPF=checking mail collector to
maintain a forwarder whitelist. To be most useful in blocking unwanted
mail, this whitelist should be per-user, and that is a lot of effort.
DKIM shows promise as an addition that can assure that an entire
message arrives intact, but it does not assure that the message was
authentic in the first place. SPF, SID, and DKIM working together
could make a tremendous difference.
If SID were ever made to work, you would have no need for DKIM. As for the
feature of making sure a message arrives intact, SES does a body hash
similar to DK. If you use SES to solve the forwarding problem instead of
SRS you also get a message integrity check without the expense of validating
the RSA signature of DK. This is the case whether you did an SES validation
or not. The body has is there in a header for you to check. OTOH, if you
do an SES validation, you are assured that the header line containing the
body hash is valid at the same time as proving the return-path is valid.
This gives you end-to-end validation of the originating MTA (necessary for
maintaining IP-based DNSBL's) as well as message content.
If SPF does indeed become popular, my prediction is that MUA's will start
displaying the return-path in addition to From:. Given the wide range of
current practice, the PRA is very difficult to establish and is of dubious
value as a single address, especially when it is the address of a forwarder.
Knowing that a message came through a particular forwarder is not useful
information for an average end user.
As for proposals to display all the relevant sender addresses, if you think
end users cannot understand return-path, how do you think they will be able
to understand Sender:, Resent-From: and Resent-Sender:?
I suspect that the strongest MUA-side anti-phishing protection that is
_practical_ is to validate and display the return-path along with From: with
an "on behalf of" statement if there is a Sender: or no Sender: but a
Resent-*:. This effectively displays the return-path, purported original
author and PRA-like address in two lines. I think an average use can deal
with two or three addresses presented in two lines: Return-Path: and From:.
I suspect this would result in a great decrease in phishing.
For MTA-side anti-phishing schemes, the world will have to get a lot
stricter in what people are willing to reject. For example, when all the
originator addresses use the same domain, validating any one of them with
any method effectively validates them all, putting sub-domain issues aside
for the moment. When the originator domains are different, are we getting
to the place where the absence of at least one authentication from each
originator domain and no whitelist entry is grounds for rejection? I don't
see us getting to that place for a _long_ time.
--
Seth Goodman
-------
Sender Policy Framework: http://spf.pobox.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