On Thu, 26 Aug 2004, Mark Lentczner wrote:
3) Incorporating scope into the record format
Several schemes have been proposed on this list for incorporating
scoping into the protocol syntax. I will summarize them here:
3a) Put scopes in the <ver-ext> field
Proposed by Wayne in
http://www.imc.org/ietf-mxcomp/mail-archive/msg03441.html
This scheme replaces the "/pra" and <ver-ext> field in the version
string with a list of scopes. For example: "spf2.0/pra,mailfrom" or
"spf2.0/mailfrom". It applies to the whole record, so it only helps
domains with very large records if their v=spf1 and spf2.0/pra records
are otherwise the same. If the above two large records were the same,
this would look like:
example.com. IN TXT "spf2.0/pra,mailfrom ... some very
long record here ..."
If the large records are different, they'd still have to resort to the
method presented in (1) above.
3b) Add a scope macro %{e}
Originally in the Unified-SPF concept, but recently proposed by Meng
in http://www.imc.org/ietf-mxcomp/mail-archive/msg03663.html
This scheme adds a macro that is replaced with the identifier for the
scope being checked: "pra" or "mailfrom". It can be used with the
include: mechanism or redirect= modifier to incorporate different parts
into mostly common record:
example.com. IN TXT "spf2.0/pra ...common...
redirect=_%{e}.%{d}"
_pra.example.com. IN TXT "spf2.0/pra ... pra only stuff ..."
_mailfrom.example.com. IN TXT "spf2.0/pra ... mailfrom only stuff
..."
If the common mechanisms work, then only one DNS query needs to be
done. Otherwise, this basically devolves into the method presented in
(1) above.
3c) Add a scope modifier
Variations discussed in the past, recently proposed by William in
http://www.imc.org/ietf-mxcomp/mail-archive/msg03677.html
This scheme adds a modifier that alters the applicable scope for the
following mechanisms until the next scope modifier. For the big
company case, this is only a help if bulk of the records for PRA and
MAILFROM are the same, and the common, plus all the difference, plus
the overhead of the scope modifier still fit in one record:
example.com. IN TXT "v=spf1 ... mailfrom only stuff ... "
"sc=pm ...common... "
"sc=m -all "
"sc=p ... pra only stuff ..."
If it doesn't fit, then it devolves into the method presented in (1)
above.
This idea has several structural problems: Modifiers would have to be
substantially reworked to achieve this "environment variable" like
behavior. The current document doesn't support such modifiers. Also,
this scheme has several important subtle restrictions to achieve
backward compatibility with existing SPF systems.
I disagree about "substantially reworked" part. Its true that currently
there are no modifiers that work like as enviroment variable, but creating
is not that hard or at least not any harder to write down in draft document
then any other scoping description. Implementing it is pretty easy too,
all programming languages allow for local and global variables and spf
scope is likely to be global variable for the library doing spf record
processing anyway.
3-Summary)
For sites where records for Sender-ID and SPF are large, similar though
not the same, none of these methods is a win over the method in (1).
Not quite. If records for different identies are 100% different and both
are very large, then method in (1) is the only way of not overruning
DNS UDP record limit. And I want to point out too that if records are so
large as not not fit one record, you'd have to split it among two or more
record by using include or redirect anyway.
At the same time if records are large but contain primarily shared/same
portion the in 3c you can have this shared portion as part of the main
and if differences are small, the total would not overrun UDP limit.
For sites with small, similar records, only (3c) has any advantage over (1).
That would be for "large, similar records", see above. For small similar
records its also true, though there you can just enter records side-side
and not worry about overrunning UDP limit (although I personally think
that is bad and duplication should be avoided if possible).
For sites where the records are the same (claimed by many to be
the vast majority of sites), (3a) is the biggest win.
3(c) offers exactly same advantages and disadvantages as 3(a) if records
are the same (and with shortered scoping names, its even smaller is size)
example.com. IN TXT "spf2.0/pra,mailfrom ... some very long record"
vs
example.com. IN TXT "v=spf1 sc=pm ... some very long record"
-------
I want to point out another important point for comparing different record
formats that originally caused new spf version string to be incorporated
into current version of MARID documents. That is if we want separate
MARID PRA identity in record format in such a way that current base of
SPF record do not apply so as not to create confusion for different
clients.
In case of 3(a) this is true as we have new version string (same as has
been achieved now), however to support this new version with mailfrom
identity ALL existing SPF records would have to be republished and
duplicated (so that both SPF1 and SPF2 clients can see them).
In case of 3(b) if main SPF version stays the same "v=SPF1" and record
is the same for different identities, then and MARID-aware client can not
tell the difference between that being origional SPF1 record that was
never supposed to apply for MARID and record that is shared between
MARID PRA and Mail-From identities, so original goal is not meat. However
if we do change version string, then we have same problem as what I
described above where existing SPF base has to publish both new version
records and old SPF1 records for compatibility with different clients.
In case of 3(c) the objective is meat because if there is no scope modifier
then client can assume to be old not-yet updated SPF1 record that applies
only to mail-from identity. At the same time when domain owner does update
the record to support both mail-from and pra, he would not have to duplicate
the mail-from part of the record to support both old spf1 and new spf2
clients (as is likely the case with 3a and 3b).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net