[Top] [All Lists]

Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I believe)

2004-08-26 14:13:24

I'm not going to weigh in on the underlying debate here, but I'm going to inject some information that might be useful:

1) Domains with large records will overflow the UDP limit:
Domains with large records that want to publish large, different records for under both v=spf1 and spf2.0/pra can do so as follows:             IN TXT "v=spf1 redirect=_spf1.%{d}"             IN TXT "spf2.0/pra redirect=_spf2.%{d}" IN TXT "v=spf1 ... some very long record here ..." IN TXT "spf2.0/pra ... some different very long record here ..."

Yes, this will require two DNS lookups (though both can be cached the same as the one, so any reasonable TTL makes this less of an issue). Neither query will fall over to TCP (assuming the long records are individually under the UDP limit)

2) Wildcards
All the major points about wildcards have been made: Essentially, they don't work the way you'd like them to whether or not there is a prefix -- it is the nature of DNS wildcards.

On the other hand, if a domain uses wildcard MX records, then wildcard TXT and/or SPF2 records can be used to achieve a matching effect. See the protocol-03 draft for an example and discussion of just this point. I will only add here that publishing under a prefix or not makes no difference - the use of wildcards has the same caveats and difficulties.

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 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: 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 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: IN TXT "spf2.0/pra ...common... redirect=_%{e}.%{d}"        IN TXT "spf2.0/pra ... pra only stuff ..." 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 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:             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.

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). For sites with small, similar records, only (3c) has any advantage over (1). For sites where the records are the same (claimed by many to be the vast majority of sites), (3a) is the biggest win.

        - Mark

Mark Lentczner

<Prev in Thread] Current Thread [Next in Thread>