Tim Draegen wrote:
Hi, I posted some feedback on the proposed SPF modifiers on the MARF
I'll have to check that out.
Here are my relevant-to-SPF comments:
- I'm having a hard time understanding how the SPF "reportopts" will be
used. The publisher of the record adds the policy piece of SPF that
leads to a (fail, softfail, neutral) result, usually by adding
something like "-all" or "~all" to their record.
EG, using the proposed syntax, I could write "v=spf1 ip4:184.108.40.206
report=email.address reportopts=f ~all". This would specify that I want
reports on all SPF "fails" (distinct from "softfails"). However, my
"~all" means that all my non-authorized email will end up receiving
"softfails", resulting in me receiving zero reports.
- Lots of real-world SPF records "include:" other records. What if two
report-related extensions appear due to the use of include:?
I'll have to check out that draft-ietf-marf-dkim-reporting draft, but I'd
hope that all non-top-level "report=" modifiers are to be ignored.
I think such a modifier should only ever concern the *sender* domain
("sender" as specified in RFC 4408, section 4.1).
- SPF records describe "mechanisms" for identifying authorized servers
and "modifiers". The extensions are "modifiers", but I'm uncertain if
these will break existing SPF code, or if various implementors did the
right the thing.
They SHOULD ignore unknown modifiers, but I hear what you're saying.
FWIW, the RFC 4408 test suite <http://www.openspf.org/Test_Suite> has a
test case named "modifier-charset-good" that effectively tests for
whether unknown modifiers are tolerated and ignored:
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/
RSS Feed: https://www.listbox.com/member/archive/rss/735/2183229-668e5d0d
Modify Your Subscription:
Powered by Listbox: http://www.listbox.com
Description: This is a digitally signed message part.