scott at kitterman
Jan 20, 2009, 6:28 AM
Post #3 of 3
On Tue, 20 Jan 2009 11:38:34 +0100 Alessandro Vesely <vesely [at] tana> wrote:
Re: Worthiness of SPF by scope: helo, mfrom, and pra
[In reply to]
>I'd like to be comforted by usage statistics, but have no data. My
>understanding of SPF checks by scope is as follows:
>helo: could work always, however hostmasters don't usually add all
>necessary DNS records; easily worked around using address literals.
It does seem to me to be increasing based on my occassional looks at
results from the SPF test reflector I run from the project. More
evangelism and better documentation is needed (who was going to send me web
site changes ??).
>mfrom: provides some protection (proportional to adoption); requires
>SRS or other machinery in case of forwarding; difficult to test and debug.
The biggest problem with mfrom is it requires domain owners to understand
and control their outbound email architecture. It's only hard to debug if
you don't understand your systems. This is quite common and one of the
reasons for long deployment times in large organizations.
Forwarding is an issue, but I think manageable. It's a tiny and declining
fraction of email.
In the long run traditional forwarding is, IMO, dead. Any forwarder will
inevitably forward enough spam to get blacklisted or lose enough mail to be
Generally, the only forwarding relationships that will survive are ones
where the receiver has made specific arrangements to bypass normal spam
checks. SPF checks would fall into this.
If a sender is genuinely concerned about the forwarding problem they can
use one of SRS/SES/BATV and an SPF record with exists backed by a DNS
database to explicitly authorize forwarded mail.
SRS would work too.
>pra: only works for bots, banks, or domains whose users never write to
>a mailing list (unless the list adds resent-* headers; any?)
>Visibility is easily worked around using resent-* headers.
PRA is useful only to a receiver as an input key to domain reputation
database. DKIM is a better way to solve this exact problems. For senders,
PRA is a very handy way to protect the resent-sender header.
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com