>...
>On 10/23/2006 7:01 PM, John Rudd wrote:
>> Eric A. Hall wrote:
>>> http://www.ehsco.com/misc/spamassassin/std_compliance.cf might help or
>>> work for what you're doing.
>>>
>>> Make sure to read the disclaimers and warnings
>>
>> Those helped a lot. There's only three checks I can't do with them
>> (probably need to use a plugin for it):
>>
>> a) does the hostname in the PTR record point to a CNAME instead of an A
>> record
>
>That's not illegal. It's pretty common too, since subnet delegation of
>in-addr space only works on /8, /16 and /24 subnets due to the way that
>octets are mapped to domain name labels in that hierarchy.
>
Eric,
I think you either misread, or have it backwards; Indeed a PTR
to a CNAME is illegal (RFC not on the fingertips at the moment). What
is *very* common is a CNAME to a PTR (which *is* legal). Example:
% host 64.32.188.109
109.188.32.64.in-addr.arpa is an alias for 109.104/29.188.32.64.in-addr.arpa.
109.104/29.188.32.64.in-addr.arpa domain name pointer smtp.mpa0.Plectere.COM.
>> b) does the hostname contain it's IP address in _hex_ form (instead of
>> in decimal form, which I've already got working)
>
>I don't recall ever seeing that. If you create a rule for that you might
>also want to do octal notations too, which is another valid address
>encoding syntax that should never appear naturally.
>
>> c) does the hostname in the PTR record actually going to an A record
>> which includes the relay's IP addr
>
>that's a reasonable test
Also called FCrDNS (i.e. "Full Circle reverse DNS").
>
>--
>Eric A. Hall http://www.ehsco.com/
>Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
>
Paul Shupak
[EMAIL PROTECTED]
