stuart wrote:
On Wed, 21 Jan 2009, alan wrote:
several have commented with all the v1 and v2 records in place and now a v3
on top
will add too much byteweight to the response to a query for UDP to handle
efficiently {or at all in some cases}
this is a serious issue {was my problem with spf originally as it broke my
standard of adding txt and rp records to most hosts
{now just rp pointing to a txt container}
so should we be considering a standard sub-zone for spf going forward?
no its simpler to fix than that
just recommend anyone doing more than 1 form of spf and/or sender-id
remembers about the issue and divides his records(s) appropriately
like thus
domain.tld IN SPF "v=spf1 redirect=_spf1.%{o}"
domain.tld IN SPF "v=spf3 redirect=_spf3.%{o}"
domain.tld IN TXT "v=spf1 redirect=_spf1.%{o}"
domain.tld IN TXT "spf2.0/mfrom,pra redirect=_spf2.%{o}"
domain.tld IN TXT "v=spf3 redirect=_spf3.%{o}"
That puts all that TXT data into a UDP packet - thus the "byteweight" problem.
One suggesting that *would* help is the standard subdomain:
_spf.domain.tld IN SPF "v=spf3 ..."
no you mis-understand i was countering my own standard sub-domain argument with
redirects as the solution
the 3 redirects to 3 separate {standard or entirly up to the user} subdomains
carry less *byteweight* than an average spf and sender-id record combined
it also means the dns server with no spf at all wouldn't have to deal with the
2x load generated by the addition of a standard sub-domain to spf-clients
{assuming they check domain if no spf-found for standard-sub-domain for
backwards compatibility and query for both SPF then TXT dns RR's}
this way non spf publishers just see 2 lookups {spf then txt} {as they do now}
spf-publishers publish only redirects in the txt/spf for domain, to their own
delegated role sub-domains
when as hoped spf v3 usurps all need for spfv1 and sender-id records. the spf1
and spf2.0 redirects and sub-zones can be dropped
clients read only the highest supported record type out of first query and thus
only 1 of the followed sub-zones
and total *byteweight* of the largest record in the zone is only variable by
length of sub-zone-name used
in my example about 64 out of of the max payload of 512 was used so plenty of
room for spfv4 5 6 which {if we do it right once} hopefully won't happen
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com