I would take this one step further.
HELO checking with SPF stops certain kinds of forgery, has no significant
downside, and is likely to be adopted iff we provide some clear guidelines
to using it. I think some effort to push it "separately" would be worthwhile.
SPF "mail from" checking is not widely used, and I think the reason is
largely the fact that mail forwarding is so widespread, and SRS is
not deployed. My experience is that email forwarding is much beloved,
and it will not go away any time soon.
Setting a "mail FROM:" address that is not that of the originating server,
is also a much beloved behavior (I do it), and will not go away soon.
Anyone wit a vanity domain likely knows about this.
Ultimately, stopping SPAM will depend on getting a chain of responsibility
into SMTP. SPF is an attempt to use DNS as a lightweight authentication
scheme for mail servers (MTAs). Making SRS useful would require
a high percentage of MTAs to adopt it. I don't see a trend in that
direction.
To some extent, what is suggested below is HELO checking. If MTAs
use SPF on HELO, they can trust that some headers (HELO names and IPs)
are trustworthy, and spam can be reliably tracked back to
the last non-trusted IP. The "ESMTP" extension could be as simple as
a flag of some sort saying "I checked the originating IP of this
message with SPF".
Deployment depends on minimizing downside. Admins are gun-shy about
anti-spam systems that cause them troubles, and anything that
has a risk of false positives is going to have a tough time.
Deployment also depends on being simple. Admins will not likely deploy
something that they don't understand. I think SRS suffers from being
too complicated for admins to be comfortable with it.
We should be cautious about trying to deal with the "IP training" problem.
SPF does not try to specify what happens when the user presses the
"this is spam" button, and we should leave that up to the blacklists
and anti-spam vendors. If we provide clear guidance, they will follow along.
The last thing they want is false positives.
-dgl-
I think the approach to dealing with forwarders needs to change. In
particular, I think we should sideline SRS and work on some kind of SMTP
extension to make forwarder whitelisting easier.
Specifically, I'd like to see an ESMTP extension where a sender can say
"I'm a forwarder, the recipient knows me as X and trusts me, so don't
SPF-check this message". X would be an identity that the recipient MTA
would check against a whitelist, and it would contain a domain so the
sender IP's right to claim that identity could be verified using SPF-like
DNS records.
Unlike SRS, which places significant burdens on the forwarder, this would
only require a software upgrade. Also, if the feature were available,
forwarders would have incentive to use it even if there was no SPF.
Consider what happens when spam makes it past a forwarder's own defenses.
Two bad things can happen:
* First, the recipient mailbox might have more sensitive content-filter
defenses, and reject the message at DATA. This leaves the forwarder
holding the hot potato -- they have to either risk silently dropping mail,
or risk emitting backscatter.
* The end-user might have a "This is spam!" button which trains an IP
blacklist, and be unaware of the implications of so tagging the forwarded
spam. Eventually the forwarder would develop a black reputation and be
unable to pass any mail to that mailbox, even though they aren't
themselves spam supporters.
The hypothetical extension would solve both of these problems in passing.
If the recipient trusts a forwarder enough to stand down SPF, they can
easily also stand down the IP-blacklist training and content filtering. By
solving these pre-existing problems, we can perhaps make the effective
deployment burden for the forwarder negative, and thus actually see some
uptake.
(SRS, in contrast, doesn't help with the IP training problem, and it makes
the hot-potato problem worse, since the forwarder assumes responsibility
for relaying the recipient's backscatter.)
This approach places a greater burden on the recipient than in the
original plan -- where all forwarders switched to SRS, and all recipients
applied a universal reject-on-SPF-fail policy. But it's an improvement on
the status quo, where nobody uses SRS and manual, unreliable whitelisting
of forwarder IP addresses is a prerequisite to acting on SPF "fail" or
"softfail" results.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------
Sender Policy Framework: http://www.openspf.org/
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/?list_id=735
-------
Sender Policy Framework: http://www.openspf.org/
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/?list_id=735