(note: this is somewhat of a re-hash of my earlier "fm="
forwarder-mitigation modifier. But the DKIM connection has been dropped,
and adding this in a new version of SPF would both be more productive and
allow simpler syntax.)
I propose that in SPFv3, we add a new result, called "rawfail" and
selected with the character "/". I call it "rawfail", not "hardfail",
because the difference between it and "fail" is qualitative, not merely a
change in intensity.
"rawfail" recommends that a message be rejected always, ignoring the
possibility that a message may have failed SPF only because it passed
through a traditional forwarder. Coupled with the addition, v3 "fail"
would be explicitly defined to merely recommend rejection *if and only if*
the recipient MX is sure that the message is not a forward.
"fail" remains distinct from "softfail", in that "softfail" does not give
a strong recommendation to reject in the case that the message is known
not to be a a forward.
I don't expect recipient MX's in practice to "obey" rawfail if they in
fact have a forwarder whitelist and the message matches. But that's not
the point. Rather, the goal is to get the many MXes out there that do not
have the information needed to tell forgeries from forwards, to block on
rawfail and not on fail.
While at first glance, getting entities to not block on fail may seem
like a step back, in the long run it is two steps forward. SPF is only as
good as its senderside deployment, and a big problem at present is sites
that publish ?all for no other reason than to make sure their mail gets
through even if it is forwarded. That in turn means that no mailbox --
not even vanity-domain ones where the admin is confident there are no
incoming forwarders -- can be protected from incoming forgeries of those
sites.
Rawfail's main benefit is to remind implementors that fail is not to be
implemented with the semantics we assign to rawfail -- it doesn't need to
be actually used by senders to give this benefit.
Still, it would be a nice option for the sender to have. Some senders
may choose "/all", accepting responsibility for the lower deliverability
in order to supress more forgeries. And it would be of obvious value to
those using the VERP / exists / magic-DNS approach.
It would be especially propitious to do this during an incompatible
upgrade, as that would deny unnecessary-"?all" users the excuse of needing
to get through to sites that haven't upgraded. Such senders could
continue to publish "?all" in their SPFv1 records, and "-all" in their
SPFv3 records. At the same time, this would provide an incentive for
receivers to upgrade.
---- Michael Deutschmann <michael@talamasca.ocis.net>
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110130080251:5BB21616-2C71-11E0-A5F4-9B4F447FCC7C
Powered by Listbox: http://www.listbox.com
forwarder-mitigation modifier. But the DKIM connection has been dropped,
and adding this in a new version of SPF would both be more productive and
allow simpler syntax.)
I propose that in SPFv3, we add a new result, called "rawfail" and
selected with the character "/". I call it "rawfail", not "hardfail",
because the difference between it and "fail" is qualitative, not merely a
change in intensity.
"rawfail" recommends that a message be rejected always, ignoring the
possibility that a message may have failed SPF only because it passed
through a traditional forwarder. Coupled with the addition, v3 "fail"
would be explicitly defined to merely recommend rejection *if and only if*
the recipient MX is sure that the message is not a forward.
"fail" remains distinct from "softfail", in that "softfail" does not give
a strong recommendation to reject in the case that the message is known
not to be a a forward.
I don't expect recipient MX's in practice to "obey" rawfail if they in
fact have a forwarder whitelist and the message matches. But that's not
the point. Rather, the goal is to get the many MXes out there that do not
have the information needed to tell forgeries from forwards, to block on
rawfail and not on fail.
While at first glance, getting entities to not block on fail may seem
like a step back, in the long run it is two steps forward. SPF is only as
good as its senderside deployment, and a big problem at present is sites
that publish ?all for no other reason than to make sure their mail gets
through even if it is forwarded. That in turn means that no mailbox --
not even vanity-domain ones where the admin is confident there are no
incoming forwarders -- can be protected from incoming forgeries of those
sites.
Rawfail's main benefit is to remind implementors that fail is not to be
implemented with the semantics we assign to rawfail -- it doesn't need to
be actually used by senders to give this benefit.
Still, it would be a nice option for the sender to have. Some senders
may choose "/all", accepting responsibility for the lower deliverability
in order to supress more forgeries. And it would be of obvious value to
those using the VERP / exists / magic-DNS approach.
It would be especially propitious to do this during an incompatible
upgrade, as that would deny unnecessary-"?all" users the excuse of needing
to get through to sites that haven't upgraded. Such senders could
continue to publish "?all" in their SPFv1 records, and "-all" in their
SPFv3 records. At the same time, this would provide an incentive for
receivers to upgrade.
---- Michael Deutschmann <michael@talamasca.ocis.net>
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110130080251:5BB21616-2C71-11E0-A5F4-9B4F447FCC7C
Powered by Listbox: http://www.listbox.com