In <1163576235.473.77.camel@bash...-64-142-13-68> Douglas Otis <dotis@mail...> writes:

> On Tue, 2006-11-14 at 12:16 -0600, wayne wrote:
>> In <1163520010.24789.222.camel@bash...-64-142-13-68> Douglas Otis
>> <dotis@mail...> writes:
>>
>> > The SPF script language does not improve data compression.  APL RR
>> > (RFC3123) provides 10 times the informational density and existed prior
>> > to SPF development.
>>
>> *sigh*
>>
>> Where do you get this "10 times" claim from?
>
> Don't ignore the overhead added to SPF scripts, such as various tags and
> record chaining.  CIDRs listed in 10 chained TXT resource records used
> by Paypal.com can be accomplished within a single APL RR, for example.


*sigh*

let's check your claim about paypal.com that paypal.com can use a
single APL RR, apparently that backs up your claim that APL records
are *ten times* as short as SPF records.


OK, so let's get a list of all IP blocks that paypal currently
publishes:

(wayne@footbone) $ spfquery -debug -ip=1.2.3.4 -helo=paypal.com 2>&1 | grep ip_match | wc -l
59

huh...  paypal.com's SPF record encodes 59 different IP blocks.  So,
an APL record will need about 59*8=472 bytes. Will this fit in a UDP
packet?

spfquery -debug -ip=1.2.3.4 -helo=paypal.com 2>&1 | grep ip_match | sed 's;.* == \([0-9.]*\)  (\(/[0-9]*\) [0-9.]*):.*;1:\1\2;' | tr '\n' ' ' | sed -e 's/^/_apltest.schlit.net. APL /' -e 's/ $/\n/'
_apltest.schlitt.net. APL 1:64.4.240.75/32 1:64.4.240.74/32 1:64.4.244.74/32 1:66.135.209.192/27 1:66.135.197.0/27 1:64.4.240.64/27 1:64.4.244.64/27 1:66.135.215.224/27 1:216.33.244.96/27 1:216.33.244.84/32 1:67.72.99.26/32 1:206.165.246.83/32 1:206.165.246.84/32 1:206.165.246.85/32 1:206.165.246.86/32 1:64.127.115.252/32 1:194.64.234.129/27 1:65.110.161.77/32 1:204.13.11.49/32 1:204.13.11.51/32 1:12.155.144.75/32 1:62.22.61.131/32 1:63.104.149.126/32 1:64.68.79.253/32 1:64.94.204.222/32 1:66.135.215.134/32 1:67.72.12.29/32 1:80.93.9.10/32 1:195.234.136.12/32 1:203.49.69.114/32 1:209.63.28.11/32 1:210.80.80.136/32 1:212.110.10.2/32 1:212.147.136.123/32 1:213.219.8.227/32 1:216.113.168.128/32 1:216.113.175.128/32 1:216.177.178.3/32 1:217.149.33.234/32 1:220.248.6.124/32 1:67.72.12.30/32 1:216.113.188.112/32 1:80.66.137.58/32 1:212.208.64.34/32 1:216.113.188.96/32 1:216.33.244.6/32 1:216.33.244.7/32 1:63.80.14.17/32 1:216.113.188.96/32 1:216.113.188.112/32 1:66.211.168.230/32 !
1:66.211.168.231/32 1:64.4.240.67/32 1:64.4.240.73/32 1:64.4.240.75/32 1:64.4.244.69/32 1:64.4.244.74/32 1:64.4.244.75/32 1:64.4.240.74/32

(wayne@footbone) $ dig _apltest.schlitt.net apl | head -3
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.2-P1 <<>> _apltest.schlitt.net apl


Nope.  paypal.com can not encode their SPF records into an APL packet
without falling back to TCP.  Of course, falling back to TCP means
that a lot more overhead, almost as much as the current SPF setup.
Also, many braindead firewalls block TCP port 53, so I doubt
paypal.com would find that acceptable even if it was the only choice.


But, as I mentioned in an earlier post, APL records were used by the
RMX system.  They were rejected for good reasons.  Do you really want
to rehash all the thousands of posts from the IRTF ASRG, spf-discuss
and IETF MARID lists here?  I certainly don't.

Hint:  It isn't must paypal.com that can't use easily APL records,
yahoo.com in particular doesn't can't even come close.



-wayne

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html