[SpamCop.net - protecting the internet through technology]

[SpamCop-List] Re: empty spam...

Norman Miller exfenestrate at spammers.invalid
Fri Dec 2 22:22:40 EST 2005


On Thu, 1 Dec 2005 04:35:24 -0500, Jeff G. wrote:

> "Mike Easter" <MikeE at ster.invalid> wrote in message
> news:dmkna7$lkc$1 at news.spamcop.net...

>> jg wrote:

>>> and came up with (via Sam Spade):
>>>
>>> How do 3 bogus rDNS entries pop up and is this the result of spammy?
>>> academic question...

>> I think but I'm not sure that in this context 'bogus' simply means
>> that 'paranoid' lookup doesn't work.
>>
>> That is, if an IP will rDNS but the rDNS doesn't DNS to the original
>> IP that the report sez 'bogus' -- which seems like an unkind term for
>> that particular behavior.

> 'violates Section "INSTRUCTIONS - Adding a host - Add the reverse
> IN-ADDR entry" of RFC1033 "DOMAIN ADMINISTRATORS OPERATIONS GUIDE" at
> http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=1033#page-11 '
> would be a little long for such a purpose, don't you think?  I think
> "bogus" fits because the rdns names (the right sides of the PTR Records)
> are in fact "not genuine" because tbr1-p014001.la2ca.ip.att.net,
> tbr1-cl3.sffca.ip.att.net, and tbr1-cb10.st6wa.ip.att.net
> authoritatively don't exist, and I blame rm-hostmaster[at]ems.att.com
> (the person responsible for the zones in all three parent SOA records)
> for the whole mess.

Does it have an adverse affect on routing packets? These are intermediary
routers, here, not end-point hosts. I should think that, as long as the
packets are being properly routed, there is no _serious_ problem.

-- 
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum


More information about the SpamCop-List mailing list