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@bmsi.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
>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@bmsi.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