In
<17349(_dot_)13698(_dot_)854265(_dot_)625572(_at_)saint(_dot_)heaven(_dot_)net>
"Dick St.Peters" <stpeters(_at_)NetHeaven(_dot_)com> writes:
wayne writes:
SenderID's spf2.0 records allow domains to specify what scope(s) their
SPF records cover. If you don't want your MFROM scope used for PRA, you
can say so. Is there anybody who thinks this is not a big advantage?
I think it is nice that you can separate the PRA from the MFROM. I
don't think, as it is designed, is that big of an advantage. The
SenderID syntax requires lots of duplicate information to define two
different scopes that are very similar, but not identical. I think it
could have been designed *MUCH* better, but it was a bad hack slipped
in under Microsoft's nose at the very end of MARID. I don't think
MarkL could have done a better job without Microsoft noticing and
objecting, but that doesn't change much.
[...]
If the MFROM and PRA scopes are different, which I think everyone
agrees they are, then using different policies in different records
for them also makes sense to me. That this leads to repetition is a
consequence of the scope similarities, not poor design. You could, I
suppose, use a baseline plus two deltas design, but I can think of
multiple reasons not to do that, especially with a deployed base of
MFROM policies in an existing syntax.
Most of the time, the MFROM and PRA scopes are identical. When they
aren't identical, they are almost always or very close.
There are several problems with simply creating two, nearly identical,
records:
1) You have to maintain the same info two different places, which is
error prone.
2) Since SPF records don't allow comments, it is hard to tell if a
difference is intentional, or an error.
3) It can be hard to spot the differences, or tell if there aren't
any.
Say the only difference between your MFROM and your PRA is that
sometimes you have an ESP deal with bounces, so you need to have an
include:mydomain.esp.com in your MFROM scope.
There have been several ways to make cleaner:
1) add scoping to the include: and redirect= mechanisms. Something
like this:
TXT "spf2.0/mfrom include:mydomain.esp.com redirect=%{d}/pra"
TXT "spf2.0/pra ip4:1.2.3.0/24 ip4:2.3.4.0/24 -all"
That is, on the include: and redirect= mechanisms, you can add a
"/" followed by a list of scopes that you want to use instead of
the current scope.
Note that this technique could easily allow everyone to say that,
yes, SPFv1 records can be used for the PRA scope with one small,
constant record. Something like;
TXT "v=spf1 ip4:1.2.3.0/24 ip4:2.3.4.0/24 -all"
TXT "spf2.0/pra redirect=%{d}/mfrom"
2) use a per-mechanism positional modifier, as defined in the SenderID
draft. Something like this:
TXT ( "spf2.0/mfrom,pra include:mydomain.esp.com scope=mfrom "
" ip4:1.2.3.0/24 ip4:2.3.4.0/24 -all" )
This "scope=" modifier can tell the SenderID implementation that
the include: mechanism is only supposed to be used for the mfrom
scope.
Note that positional modifiers, as defined in the SenderID draft
apply to only the preceeding mechanism, which is not what many
people expect. Since these modifiers apply to only one mechanism,
if you have several differences, you have to add the modifier to
each one.
3) Use a non-positional modifier to change the scope. Something like
this:
TXT ( "spf2.0/mfrom,pra ip4:1.2.3.0/24 ip4:2.3.4.0/24 "
"scope=mfrom include:mydomain.esp.com scope=mfrom,pra -all" )
This "scope=" modifier lets you change the scope being applied to
all following mechanisms. It is like setting a variable.
Note that not everyone expects modifiers to act like variables, but
instead think of them like they are defined in the SenderID draft.
If there is only one difference between the records, then you end
up with longer records than if you used SenderID-type modifiers.
Another alternative for the above would be:
TXT ( "spf2.0/mfrom,pra ip4:1.2.3.0/24 ip4:2.3.4.0/24 "
"scope=-pra include:mydomain.esp.com scope=+pra -all" )
This lets you add and delete scope values, instead of just setting
them.
Re-using most of the existing policy syntax while modifying it enough
to accommodate different policies for different scopes seems to me to
be one thing SenderID got right.
Before December 2003, the SPF spec included a "scope=" modifier which
applied to the entire record. It had almost the same semantics as the
current SenderID spec. MarkL was instrumental in removing the scope=
mechanism from the SPF spec, and simply slipped it back in. I think
MarkL was correct in removing the scope= mechanism from SPF because it
was not well defined. I think that if adding it back in wasn't done
in the two weeks of MARID's existance, and if having more than one
scope being defined for the last week of MARID's existance, we could
have done a better job. Scoping in SenderID was a rush-job and added
in a sneaky way as to not raise objections from Microsoft.
-wayne
-------
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