On Tue, 31 Aug 2004, Mark Lentczner wrote:
Re-reading this thread, looking for common ground, I see
1) There is near universal agreement that domains will still want to
publish records about the 2821 Mail From identity.
That was quite clear from the start. In fact when I first talked to Meng
on the interim meeting about combination of SPF and Caller-ID he was quite
clear that this is being done so that existing SPF records would be
supported by wider range of software including from Microsoft, and that
at the same time SPF libraries would also be upgraded to support new
type records for Caller-ID but that both would continue to exist.
2) There is still concern on where the TXT records should be published:
Either at something like _pra._marid.example.com vs. at example.com
itself.
3) It has been shown that even if records go into sub-domains, due to
the way DNS wildcards work, records still need to be distinguishable
based solely on their content, not their location.
Yes, I made this quite clear.
But after rereading David Blacka's last email on the subject:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03763.html
I will no longer object to putting records in subdomains, I made wrong
logical conclusion on it being useless solely because it does not achieve
scoping by itself. In fact while providing scoping as part of spf data
part is required, we can still benefit from subdomain/prefix placement
of records in case when records are in fact completely different, then
when somebody looks for one particular record type, they no longer get
the other record and we can have larger size of records in dns and do
not need to use approach of redirection that Mark previously desciribed.
But at the same time there is a downside to doing it this way too as
application, may end up doing more dns lookups. For example if application
checks for PRA record first and then for mailfrom and first one is not
published, it ends up doing second lookup for second record. While if
records were both contained at the root of the domain, the application
would only need to do one lookup.
So choose what is worth - possible problems with larger dns record size or
possible problems with larger number of dns lookups...
Therefore, I suggest that we adopt the scheme I labeled (3a):
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 ..."
The only counter to this scheme (other than some preference for the
others) was that it would require existing v=spf1 domains to
re-publish. I don't beleive this would be the case:: All existing SPF
implementations are likely to accept v=spf1 for quite some time, if not
forever. And, because it is also likely that all existing SPF
implementations would be rev'd quickly[1] to support spf2.0/mailfrom,
then new sites can simply publish the new version.
You're assuming that existing SPF implementors want to support PRA which
maybe an issue because of Microsoft licese requirements. If implementors
don't want to support PRA, they have no reason to not coninue to only work
with SPF1 records.
There is a solution available which completely supports existing SPF base
and as I already posted before:
example.com. IN TXT "spf2.0/pra,mailfrom ... very long record ~all"
is completely (100%) equivalent to:
example.com. IN TXT "v=spf1 sc=p,m ... very long record ~all"
Because in case of records being equivalent a scoping modifier is
interpreted exactly the same way as version modifier for entire record.
[1]: There aren't that many existing implementations, and everyone
running one knows that they are running less than 1.0 code and
generally is keeping an eye on updates.
I hope you're right, but if I remember the talk about merging SPF and
CallerID was so that existing SPF record could be supported by both.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net