John Rudd wrote:
> Botnet isn't a DNSBL...
>
I never said it was a DNSBL.
But it definitely has a particular focus on the sending IP, and that
sending IP's rDNS. Therefore, for all practical purposes, it is trying
to do the job of a DNSBL. As I recall, the discussion about BotNet's
development centered around blocking spam based on the sending IP...
where that IP didn't have time to get into the DNSBLs.
You might argue that a DNSBL could never replace the BotNet Plugin
because the BotNet Plugin will always catch at least some spam that
hasn't had time to get into a DNSBL. Fair argument--except that this
argument is greatly diminished if/when there are high-quality/low-FP
DNSBLs which are fast reacting/updating/distributing. Especially since
DNSBLs "scale" much better than the BotNet Plugin... and especially
if/when such DNSBLS have lower FPs than the BotNet Plugin.
I did a quick cursory search of discussions about BotNet Plugin FPs. See
attached for an example post I quickly grabbed after searching just a
few seconds.
NOTE: I'm NOT saying that the BotNet Plugin is bad or shouldn't be used.
I just don't see it as a SaneSecurity replacement. And I thing it is
probably better used as a scoring list instead of a blocking list.
--
Rob McEwen
http://dnsbl.invaluement.com/
r...@invaluement.com
+1 (478) 475-9032
--- Begin Message ---
> Bret Miller wrote:
>
> > Enews.webbuyersguide.com (part of Ziff-Davis Media), sent from IP
> > 204.92.135.90, resolves to smtp22.enews.webbuyersguide.com
> #not sure why
> > this got a BOTNET=1 flag, but it did. Also find hosts 92,
> 75, 70, 74, 93,
> > 86, and others. All similarly resolve to
> smtpnn.enews.webbuyersguide.com.
>
> baddns. baddns means lack of full circle DNS. In this case,
> the name
> returned by the PTR record (smtp22.enews.webbuyersguide.com) does not
> resolve at all ... let alone not resolving back to the
> sending IP address.
>
>
> > meridiencancun.com.mx, sent from IP , resolves to
> > customer-148-233-9-212.uninet-ide.com.mx #more stupidity
> >
> > Wordreference.com (WordReference Forums), sent from IP 75.126.51.99,
> > resolves to www2mail.wordreference.com, again no idea why
> it gets flagged.
>
> # nslookup www2mail.wordreference.com
>
> Non-authoritative answer:
> Name: www2mail.wordreference.com
> Address: 75.126.29.11
>
> baddns.
>
>
> > AltoEdge Hardware, sent from IP 69.94.122.246, resolves to
> > server.nch.com.au, another no idea why BOTNET=1, but it
> does. Just out of
> > curiosity, I ran this through again with debug enabled so I
> could get more
> > details. Here's what it says:
> >
> > [2472] dbg: Botnet: starting
> > [2472] dbg: Botnet: no trusted relays
> > [2472] dbg: Botnet: get_relay didn't find RDNS
> > [2472] dbg: Botnet: IP is '69.94.122.246'
> > [2472] dbg: Botnet: RDNS is 'server.nch.com.au'
> > [2472] dbg: Botnet: HELO is 'server.nch.com.au'
> > [2472] dbg: Botnet: sender 'adm...@server.nch.com.au'
> > [2472] dbg: Botnet: hit (baddns)
> > [2472] dbg: rules: ran eval rule BOTNET ======> got hit (1)
> >
> > I'm not sure what it means. The IP resolves to
> server.nch.com.au and it
> > resolves to the IP. Not sure what is "bad" about dns here.
> I'm also not sure
> > what headers botnet looks at. The top Received header is
> ours and the others
> > are all internal to the sender.
>
> # nslookup server.nch.com.au
>
> Non-authoritative answer:
> Name: server.nch.com.au
> Address: 69.94.122.247
>
> So, server.nch.com.au's name does not resolve back to the sending IP
> address, thus baddns.
OK... I guess I didn't check closely enough. But the point is still that
users expect these emails and complain if they don't receive them. Today's
list were mostly just top offenders, and it's going to take me time to make
exceptions for all the servers we receive email from that are badly
configured dns-wise.
Maybe these aren't false positives because botnet is identifying them for
what they are-- badly configured. But to give a rule like botnet a default
score that's high enough to consider the messages spam all on its own causes
users to think we have a bad spam filtering program.
When I see on the list that many people run botnet with ZERO false
positives, I have to ask myself, "how? And why is our setup here so
different?" Perhaps they already block email with invalid rdns at the MTA
level, so none of this ever gets looked at. Perhaps their users just give up
when they don't get email that they expect and use a free email account
instead for that email. I don't know, but botnet hits a significant amount
of legitimate email here, regardless of how badly configured the sending
servers are.
I just don't have the option of telling our president's assistant that "we
can't accept email from your husband because the IT department at the City
of Pasadena won't fix their DNS issues for their email server." That's just
not acceptable in a corporate environment, even if she had a clue what the
statement meant besides that I was refusing to do what she wants. The
majority of these badly configured servers won't ever get fixed unless
someone that matters to them stands up and tells them they need to fix it. I
do that when I can, but most of the time I just don't matter enough to get
it done.
Bret
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
