On Mon, 6 Jul 2009 01:10:01 -0700 (PDT) Michael Deutschmann
<michael(_at_)talamasca(_dot_)ocis(_dot_)net> wrote:
On Sun, 5 Jul 2009, Stuart D. Gathman wrote:
But [forwarding] is not something the sender can or should worry about
when setting a *sender* policy.
The sender can still offer an opinion about how the receiver should
balance the risks.
I'm interested in some evidence that receivers are interested in this.
I've explored similar ideas with mail providers and anti-spam vendors in my
consulting work and gotten no traction.
Some senders don't see any point in taking risks with their deliverability,
however minor, just to help strangers detect forgeries.
I don't see a new modifier changing this.
But others may see SPF as valuable only as a backscatter preventer, and
presently not very effective because sane ISPs will not turn SPF on
globally.
They would love to use "fm=hard" to tell a receiver "go ahead and ignore
the
forwarder problem; I accept responsibility for the FP risk.".
This is what the current -all means (to a very close approximation). Why
would receivers believe this if they don't believe -all.
For backscatter prevention all that is needed for most domains is
sufficient deployment to deter spammers from using that domain. In general
we seem to have that now (there are some spammers that aren't deterred, but
most seem to be).
Also, don't forget the potential for fm values other than hard or soft,
which can advise the receiver of alternative ways to recognize legitimate
forwarded messages. I already suggested "fm=dkim" in the original thread.
This pretty well removes the bandwidth/processing advantages of SMTP time
rejection as you have
to receive the entire message to find out if it has a valid signature (this has
been proposed
before).
Another possibility is "fm=callback", which would be used by senders using a
SES/BATV type scheme. This would explicitly invite the receiving server to
do callback verification in the event of a non-PASS SPF result. While that
would be a much clunkier protocol than DKIM, it could be implemented much
faster.
SES/BATV proponents have long pointed out that their proposals would
terminate forgeries if everyone did callback. But everyone will not use
callback, since some of us consider it abusive. And some systems will give
misleading results and/or cause auto-blacklisting. But "fm=callback" would
resolve this by indicating informed consent and promising that callback
will
give useful information.
You can embedd batv/ses checks in your SPF record with exists and no
protocol extensions are required.
A streamlined version of the above would be to have an "fm=unneeded",
option, which would indicate that a false SPF Fail result is simply
impossible, due to an exists mechanism which queries SES/BATV validity via
a
custom DNS server. This would be even harder to implement on the sender
end
than DKIM, but would be downwards compatible to receivers ignorant of fm=.
There has been some discussion of treating "v=spf1 -all" records
differently because there's no risk of false positive. Beyond that, I
don't think a false positive is impossible (it's not actually impossible
for "v=spf1 -all" records either).
Scott K
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com