spf-discuss
[Top] [All Lists]

Re: Re: purely dual-format approach

2004-10-30 22:53:42
On Sat, 2004-10-30 at 18:06, Frank Ellermann wrote:
as long as the scoping modifier can not remove the 
MAIL FROM or HELO scopes, a sc= modifier is completely
compatible with v=spf1.

That's a new restriction you have just added, it wasn't
part of my discussion with Roger.  Of course you can add
modifiers which have no effect at all in pure MAIL FROM
evaluations.

Just to be clear, you assert that:

        v=spf1 sc=pra -all

when evaluated against HELO and MAIL FROM is equivalent to 

        v=spf1 ?all

or no records at all, correct?

The act of publishing records with v=spf1 implies that you want the
checks to occur against the things that SPF checks, in the same way that
publishing MX records implies (nevermind that it explicitly says) where
you want mail delivered.  If you don't want the checks to occur, don't
publish v=spf1 records.  

The only definition of what "modifier" means, from spf-draft-200406.txt,
is in section 5:

        Instead [modifiers] provide additional information or change the
        course of SPF processing.

I believe wayne (and I agree with him) that the sc= modifier is not a
modifier of the record itself but rather modifies the list of things
that can use SPF records (by adding to that list), that is "provide
additional information", and not "change the course of SPF processing". 
Both interpretations are valid in this respect.  But, what, exactly,
each modifier actually modifies, and any other rules related to the use
of that modifier, appears to be up to the definition of the modifier
itself, the meaning of redirect=, exp=, and accredit= (which are not
really consistent with each other) are precedent.  This paragraph from
Section 3.2:

        Modifiers MAY appear to the right of a terminal mechanism such
        as "all".  SPF parsers may therefore choose to extract all the  
        modifiers from a record before interpreting mechanisms.
        Alternatively, they may continue to parse a record in search of
        a meaningful modifier even after mechanism evaluation has
        completed.

seems to support this.  That is, exp= only makes sense if it is needed,
and you only know if it is needed after the fact.  And redirect= is only
used if all mechanism fail to match.  And accredit= is only used if the
receiver supports accreditation checks.

In light of this, naming the modifier "additionalscopes" or "as" or
"asc" might make more sense if you don't want to break current
deployments and make it more obvious as to what exactly the intent of
using this modifier is.

As far as the case of only wanting PRA checks and not doing HELO and
MAIL FROM, the definition of PRA related specs should not solely rely on
"v=spf1" records to get their data.  First they should look for
"spf2.0/pra" records or whatever, and failing that, fall back on looking
for v=spf1 records that have an "additional scope" modifier.  This way,
obviously, if you only want PRA, you only define the PRA specific
record.  This is much more past- and future-proof and generates more
goodwill than just reinterpreting records meant for other purposes
without the record explicitly saying so.  Including modifiers in SPF was
an extremely wise decision and allows these things to happen in a
controlled and accepted manner.

But Mark's positional idea also FAILs for a PRA in v=spf1:
"v=spf1 -all only=pra" isn't any better with existing SPF
implementations.

Again, naming a scope modifier "only" doesn't make much sense because it
doesn't take into account current deployments.  I agree this would not
be backward compatible.

Adding new modifiers to v=spf1 _can_ work.  But that's not
necessarily so, anything like only=pra is a counterexample.

But you've already admitted this, removing the MAIL FROM
scope with a modifier is one of the big NoNos for v=spf1.

Heh, modifiers should not just be added willy-nilly. :)

Andy Bakun