On Thu, 26 Aug 2004, Meng Weng Wong wrote:
On Wed, Aug 25, 2004 at 08:44:16PM -0700, Rand Wacker wrote:
|
| This is a concern that has been voiced to me by several major sites that
| are exactly the same set of sites we use as examples for where we need to
| stop phishing from. They are most likely going to publish *both* spfv1
| and spfv2/pra records, and their initial investigation of their email
| architectures has indicated that those records are going to be pushing
| this real-world 240-byte limit (a 480 byte effective UDP packet split in
| two)
The divergence between v=spf1 and spf2.0/pra records was
motivated by the desire to accommodate those domains whose
sets of permitted IPs differed according to context.
This was unfortunete decision from IETF meeting largely done to
distinguish MARID records from existing SPF base. It was felt by some
that existing records are published for mail-from and may not apply
for MARID PRA and by doing new version of SPF it can be insured that
all records used are those that wanted to published MARID records.
I have to say that I share opinion that records might be different
for different identities, but I did not think there was enough
reason to force duplication as per current proposal. I had to think
about it when this was talked during MARID meeting (before ideas
of scoping modifier that me and others proposed were rejected)
and I did not immediatly object.
However the way I see it now is that although this does introduce
scoping it did in a way that will not allow for two scope records
to have shared data parts which will cause large amount of dupliction
and increase of dns records. I note specifically that records do not
even allow for different scopes to even refer to the same shared portion
of dns record (though for example include) which could potentially
provide a solution in case of large SPF record size. Overeall I think
the way the scoping was introduced with SPF2.0/PRA carries larger
negative then positive value.
Both scope macro and new prefix have their own advantage and disadvantages
and I do not like either alternative. With prefix you gain ability
to be certain that record published is indeed for MARID PRA (as spf1
records are entered directly in TXT for domain) as is with SPF2.0/PRA
but in case of shared records, it requires separate lookup which I
suppose would be done with "include". This can be avoided by using
wildcards but in that case the same record applies for all subdomains
and this may not have been the original intent. At the same time
when you do want to use wildcards, you can no longer proper publish
scope, which is actually a bigger concern.
With scoping macro, it easily solves the problem for SPF1 & MARID PRA
records having same data but at the same time main objection of new
version of SPF2.0/PRA was to distinguish when publisher intended
to use PRA or not and in case of completely same data, you may never
know. At the same time if data is not the same, this will ALWAYS require
2nd dns lookup which is even worth, so I think spf macro is worst choice.
I do have an alternative idea though (and its not anything knew that was
not already mentioned before). This involves introducing new operator
that specifies scope (i.e. "scope=PRA") and requirying that to be present
if record is to be considered valid for MARID PRA. If somebody needs to
specify portion of SPF record that is not covered by PRA but should be
understood by old SPF1 complient client, then such record would go
before "scope=PRA", the shared portion would have to be proceeded by
"scope=PRA,MFROM". In rare cases when you have record that should
be covered only by PRA but should not be ignored by SPF1 client, I
propose that "scope=MFROM ?all" (or ~all or -all, etc) be placed
followed by "scope=PRA" and rest of the record for PRA and repeat
of the ending ?all. To give an example:
example.com. IN TXT "v=spf1 scope=MFROM +ip4:192.0.0.1
scope=PRA,MFROM +ipf:192.0.0.2
scope=MFROM ~all
scope=PRA +ip4:192.0.0.3 -all"
In above current (SPF1 only clients that don't know about PRA and scoping)
would see above as only: "v=spf1 +ip4=192.0.0.1 +ip4:192.0.0.2 ~all"
where as new scope aware clients will see this same way for old SPF1
scope of enevelope "mail from" but will see this as
"+ip4:192.0.0.2 +ip4:192.0.0.3 -all" for PRA.
Now what I actually proposed before is short versions for operator names
(in order to have shorter dns records) where each scope is represented by
one letter so instead of long "scope=PRA,MFROM" we can have "sc=pm" or
possibly "sc=p,m".
I would appreciate if these ideas and this form of scoping identifier are
reconsidered especially if decide to go with anything like unified SPF
instead of (or in addition to) current MARID PRA proposal.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net