On Tuesday, January 25, 2011 11:38:45 am you wrote:
Tim Draegen wrote:
Hi, I posted some feedback on the proposed SPF modifiers on the MARF
IETF list.
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:1.2.3.4
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).
I generally agree, with the slight modification that I think such modifiers
which appear after following redirect= should also be applied (this is in my
mind analogous to the policy result (*all) coming from the record the domain
is redirected to. So I would suggest ignoring such modifiers coming from an
include: mechanaism (the result of include and only be match/not match or an
error condition), but specify that modifiers following a redirect modifier
should be processed. This needs to be specified in the document.
- 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:
http://www.openspf.org/svn/project/test-suite/rfc4408-tests-2009.10.yml
Additionally, there have been enough false starts towards new modifiers over
the last few years where some small number of people involved in SPF
development published modifiers that are unknown to RFC 4408 that I think if
there were significant implmentations in the wild that had a problem with this
we'd have heard about it by now.
Scott K
-------------------------------------------
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/2183229-668e5d0d
Modify Your Subscription:
https://www.listbox.com/member/?member_id=2183229&id_secret=2183229-a7234b15
Unsubscribe Now:
https://www.listbox.com/unsubscribe/?member_id=2183229&id_secret=2183229-98aa0fe6&post_id=20110125215122:2689BEEE-28F7-11E0-9E9A-AFE6F64C79A1
Powered by Listbox: http://www.listbox.com