Greg Connor wrote:
here is where I diverge from most scope-zealots: my firm
belief is that cases where scope is really *needed* will
be very, very rare.
ACK, and so far nobody produced a case where "scopes" are
absolutely _required_ for some highly desirable feature.
Two near misses made it (as op=helo and op=nohelo) into the
unofficial "SPF section 6.3" pet cemetery.
Out of curiosity, who are the many scope-zealots, William ?
the set of servers 99% of the time will be the same set
whether the domain is used in HELO, MAIL FROM, or 2822.From:.
That reminds me, in December there was a discussion "does
anybody evaluate spf2.0/pra ?", and it turned out that that's
the case. The thread then went into details about statistics
of this user with _different_ v=spf1 and PRA policies.
He had (simplified) six sets of IPs: PASS.spf, PASS.pra,
DUNNO.spf, DUNNO.pra, FAIL.spf, and FAIL.pra. The last set
was empty in his casae (no PRA FAIL).
I think that for all users with both SPF and PRA policies the
set PASS.spf "must" be always a subset of PRA.pass if they're
not simply identical. And FAIL.pra "must" be always a subset
of FAIL.spf.
He had the latter (empty FAIL.pra is a subset of FAIL.spf) but
IIRC not the former, that's odd, isn't it ? If there's a route
where SPF results in PASS, but PRA results in less than PASS,
what is he actually doing with this route ?
if the way domain owners use MAIL FROM: is pretty different
from the way they use HELO (or even 2822.From:), usually
defining one list of servers that merges both sets is a
pretty easy proposition.
Yes. Where "merging" could be the intersection of the PASS
and FAIL sets resp., and anything else going to the DUNNO set.
Loses some information. So you might try to use the union of
the PASS sets instead of the intersection, if the difference
is in practice irrelevant (HELO tends to be less relevant, if
the real HELO IPs get a PASS and most other IPs a FAIL it's
good enough, same idea as "just take /24 if you're not sure").
If you trust a certain IP to use your domain as MAIL FROM,
why not take the simple route and say that it's allowed to
use your domain as HELO as well, even if it never does?
Merge the two lists of machines and get on with your life...
+1 I got no urgent requests to publish op=nohelo in 2005 ;-)
For example, if your MAIL FROM policy ends in ?all and you
want a more restrictive HELO policy that ends in -all, you
can still have the bulk of the record in the middle be the
same
JFTR, also no urgent requests to publish op=helo last year.
In practice these HELO-subtleties are apparently irrelevant,
and in theory they could be solved with "options".
I want to encourage people to use the *same* spf code for
multiple identities.
Well, and here we're stuck. Those who don't want PRA have no
reason to migrate from v=spf1 to spf2.0/mfrom. Those who want
both cannot simply say only spf2.0/mfrom,pra, because many SPF
implementations supporting v=spf1 won't look for a "mfrom" in
spf2.0, let alone support the spf2.0 positional modifiers.
The other way op=pra also got no traction. As Wayne said the
PRA-folks don't care, they want SID only for marketing, or as
William said for EEE, the unfriendly takeover sponsored by Mr.
Hardie and his DEA-directorate.
Given the above beliefs, I envision scopes as either
positional modifiers (reasonably OK) or as macros (best).
[...]:
"a mx ip4:10.1.2.0/24 redirect=%{scope}.spf.%{d}"
I know a lot of people don't like macros because they are
complicated, but if you believe as I do, that people will
rarely need diverging scopes, it makes some sense.
IIRC that idea was Meng's %{e} in MARID discussions. I'm not
sure, in the last marid-protocol-03 draft there is no %{e},
and I don't have the older drafts anymore.
There should be an "official" collection of historical drafts
on openspf.org If some authors hate it when expired drafts
are available they could say so. That's copyrighted material
that doesn't automatically come with a CC-BY-SA license. The
IETF IPR WG is just discussing similar issues, but I digress.
Well, new macro => new SPF version, as for any new mechanism,
(And for some but not all new modifiers, the pet cemetery "6.3"
lists all caveats about new SPF modifiers, not only options.)
And %{e} - if that's Meng's original name - would be a major
modification, not only "add a few lines for %{e] changing all
v=spf1 into v=spf3 everywhere".
It's a new input parameter for checkhost(). At the moment
checkhost() for v=spf1 doesn't need to know which "scope" you
are trying to check. At the moment checkhost() for spf2.0
might also try to get away without this. I've no idea what
they do with a %{h} while checking PRA, one of the holes in
their spec.
At least we can trust that adding %{e} won't fly with both
v=spf1 and spf2.0, so that would be v=spf3. Or spf3.0 if you
also want to add the positional modifiers while you're at it.
Anyway, that's a part of my "vision" for the future of SPF...
practically speaking, a small part, but still somewhat
important. I look at it as an opportunity for SPF to "branch
out" in the future.
Curious minds still want to know what scopes you have in mind.
While I hate PRA in practice (and the IESG / DEA / MARID issue
is on a level as what happened in Korea), I still think that
the PRA is a valid _theoretical_ concept, and in fact the best
you can do without keys (like DKIM) for any 2822 "identities"
and the existing 2822 header fields.
You might feel that 2822.from is silly as a scope
Yes, nevertheless DKIM picked it, desperately trying to avoid
PRA. Last state I know is "the first of the From-addresses".
Bye, Frank
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com