18 Feb
2004
18 Feb
'04
11:33 a.m.
As of late I have noticed that more and more major
mail servers will
not process mail from any server [whose] forward and reverse dns do
not match exactly.
And good for them, I say. Too many places have been sloppy about rDNS
for too long.
That's not a big deal, but the way some (AOL) are
doing it, does
violate RFC's. Specifically, even if the forward and reverses DO
match, but the reverse lookup provides aliases as well, they will
toss it.
Provides aliases in the sense of returning multiple PTRs, or in the
sense of passing through a CNAME? I mention this because you say
However, this breaks an RFC-specified way of handling
delegation of
subnets on uneven boundaries.
which sounds like RFC2317 delegation, ie, CNAMEs. But my rDNS is done
2317-style, and I've had no trouble sending to AOL (though admittedly I
don't do it much).
I note that your list message was emitted from 209.83.143.147. Chasing
the DNS by hand, with a human's tolerance for mistakes, I find that
this has the name ssh.kwcorp.com. My nameserver, though, returns
SERVFAIL when queried for PTR records for it. I conjecture that this
is because when the savvis.net servers (who own
143.83.209.in-addr.arpa) are queried for 147.143.83.209.in-addr.arpa,
they return NS records naming dns1.anet-stl.com, but this is, strictly,
a lame delegation; dns1 and dns2 .anet-stl.com do not in fact serve
147.143.83.209.in-addr.arpa - they return non-authoritative answers
showing yet other nameservers.
That is, I suspect the problem arises because of the attempt to
delegate the same zone cut (the one at 143.83.209.in-addr.arpa) twice,
rather than because of aliases - I find neither multiple-PTR nor CNAME
involvement here.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B