> 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 '[EMAIL PROTECTED]' > > [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
