Re: Re: New SPF modifiers

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