I like SPF, however, I've always had a problem with the arrogant
attitude some show towards the forwarding problem -- that receiverside
implentors should ignore it to force forwarders to change. (I instead
think receivers should only deploy SPF on each mailbox once it is
confirmed that all forwarders are whitelisted.)
I find this harmful because it defeats the goal of widespread senderside
SPF deployment using "-all". Senders who, according to the intention of
the standard, qualify for "-all" will instead use "~all" or "?all"
merely to make sure their mail gets through even if they send to a user
behind a non-SRS forwarder.
This destroys valuable information -- since sometimes a site can be
"?all" for legitimate reasons, and sometimes just to dodge the forwarder
problem. Receivers who have no incoming forwards or have whitelisted
them all would really like to know the difference.
One way to avert this problem is to change the SPF deployment strategy,
as I have been calling for since I joined the list. That's not working
too well, though.
However, I have another idea: extend SPF to allow senders to signal
their intentions with respect to the forwarder problem, by adding a
"Forwarder Mitigation" option.
"fm=soft" would indicate the sender cares more about avoiding the
forwarder problem than it does about preventing forgery to users who
have not told their ISP about their forwards. It would effectively
disable SPF, but could be overridden by users who have whitelisted their
forwarders.
"fm=hard" would do the opposite, instructing the receiver to show no
mercy to possible forwards. Sites that are presently skittish about
arming SPF at the receiverside, might turn it on just for senders
carrying this flag in their record.
With these options, senders would then be free to use "-all" in all
cases where it is appropriate by the original intention of the standard.
Other "fm=" options could be used to indicate special approaches to the
forwarding problem. In particular, we could define a "fm=dkim" option
to indicate that the sender always adds a DKIM signature for the
return-path domain. DKIM isn't usually broken by forwards.
(This would also be good politics, showing that we are above the Not
Invented Here syndrome...)
A receiver that believes it has whitelisted all forwarders would be free
to ignore fm=dkim and block incoming SPF-fail e-mails at RCPT, as
before. (Which means it would be a very bad idea for a sender who
dislikes IP-based authentication to try "v=spf1 fm=dkim -all".)
But a receiver worried about the forwarding problem can let SPF-fail
e-mails past RCPT, while setting a flag that will cause rejection at
DATA if the expected signature is bad or absent.
This indication would be orthogonal to DKIM's own
SSP/ADSP/whatever-they-finally-call-it record. ADSP asserts that a
signature for the domain of the From: is required, while SPF fm=dkim
would assert that a signature for the domain of the MAIL FROM: is
required. If they are different, then in DKIM's vocabulary the
signature demanded by fm=dkim would be "third-party".
---- Michael Deutschmann <michael@talamasca.ocis.net>
-------------------------------------------
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
attitude some show towards the forwarding problem -- that receiverside
implentors should ignore it to force forwarders to change. (I instead
think receivers should only deploy SPF on each mailbox once it is
confirmed that all forwarders are whitelisted.)
I find this harmful because it defeats the goal of widespread senderside
SPF deployment using "-all". Senders who, according to the intention of
the standard, qualify for "-all" will instead use "~all" or "?all"
merely to make sure their mail gets through even if they send to a user
behind a non-SRS forwarder.
This destroys valuable information -- since sometimes a site can be
"?all" for legitimate reasons, and sometimes just to dodge the forwarder
problem. Receivers who have no incoming forwards or have whitelisted
them all would really like to know the difference.
One way to avert this problem is to change the SPF deployment strategy,
as I have been calling for since I joined the list. That's not working
too well, though.
However, I have another idea: extend SPF to allow senders to signal
their intentions with respect to the forwarder problem, by adding a
"Forwarder Mitigation" option.
"fm=soft" would indicate the sender cares more about avoiding the
forwarder problem than it does about preventing forgery to users who
have not told their ISP about their forwards. It would effectively
disable SPF, but could be overridden by users who have whitelisted their
forwarders.
"fm=hard" would do the opposite, instructing the receiver to show no
mercy to possible forwards. Sites that are presently skittish about
arming SPF at the receiverside, might turn it on just for senders
carrying this flag in their record.
With these options, senders would then be free to use "-all" in all
cases where it is appropriate by the original intention of the standard.
Other "fm=" options could be used to indicate special approaches to the
forwarding problem. In particular, we could define a "fm=dkim" option
to indicate that the sender always adds a DKIM signature for the
return-path domain. DKIM isn't usually broken by forwards.
(This would also be good politics, showing that we are above the Not
Invented Here syndrome...)
A receiver that believes it has whitelisted all forwarders would be free
to ignore fm=dkim and block incoming SPF-fail e-mails at RCPT, as
before. (Which means it would be a very bad idea for a sender who
dislikes IP-based authentication to try "v=spf1 fm=dkim -all".)
But a receiver worried about the forwarding problem can let SPF-fail
e-mails past RCPT, while setting a flag that will cause rejection at
DATA if the expected signature is bad or absent.
This indication would be orthogonal to DKIM's own
SSP/ADSP/whatever-they-finally-call-it record. ADSP asserts that a
signature for the domain of the From: is required, while SPF fm=dkim
would assert that a signature for the domain of the MAIL FROM: is
required. If they are different, then in DKIM's vocabulary the
signature demanded by fm=dkim would be "third-party".
---- Michael Deutschmann <michael@talamasca.ocis.net>
-------------------------------------------
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