On Mon, 6 Jul 2009, Michael Deutschmann 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.
Some senders don't see any point in taking risks with their deliverability,
however minor, just to help strangers detect forgeries.
At this point, not having a useful SPF record is a deliverability risk.
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.
There is *zero* risk to SPF when correctly implemented. Large (as opposed to
"sane") email providers (as opposed to ISPs) are often technically unable
to correctly implement SPF for received mail due to not having a way to track
forwarders contracted by their users. The correct (nut just sane)
thing to do in that case is not to reject on SPF. They are technically unable
to "turn on" SPF in the first place without some kind of infrastructure to
support tracking all the "informal MXes" (receiver forwarders).
SRS lets the forwarders do the job (of simplifying informal MX support for
receivers), but why would they want to? It can also be done by the receiving
email provider (e.g. web page for users to register their forwarders and opt-in
to SPF).
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.".
There is zero FP "method" risk to SPF. There is only a "user" risk of
braindead (incorrectly implemented) receivers (or mistakes in the SPF record by
the sender). The "forwarding problem" is simply an incorrectly implemented
receiver. Adding yet another useless layer to SPF for receivers to get right
is not going to improve the odds of receivers getting it right.
As to why "I really mean it" layers are useless, consider this:
http://gathman.org/papers/intense.html
For all the email I manage, there have been literally *zero* FPs due to SPF.
Most of our problems are with large providers that ignore a correct HELO
and reject DSL IPs even when not dynamic.
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.
Notifying of other authentication protocols is useful, but is already
addressed in other modifier proposals.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------------------------------------------
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