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

[Mike Easter]

jg wrote:

> Jeff, you need QuoteFix to go along with your doubtlook client - I got
> cross eyed reading the orig of above post...
> sorry...

While I'm in favor of as many people using QuoteFix as need to, my QF
fixed Jeff's post;  see below.

If yours did not, then your QF has run out of its 'memory leak space'
buffer, and you need to:

 - configure QF to 'depend on OE' in its advanced options and
 - integrate OE & QF to be 'OE with QF' and
 - periodically shutdown the OE/QF integrated operation and restart it
and
 - when you do, you are likely to find that QF works better to fix such
things


Jeff G. wrote:
> "Norman Miller"
>>  Jeff G. wrote:
>>> "Mike Easter"
>>>> 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.
>
> No, it does not "have an adverse affect on routing packets", but it
> does "have an adverse affect on troubleshooting of routing packets"


-- 
Mike Easter
kibitzer, not SC admin