Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

method and advisability of blocking Reverse DNS host None

Like many of the lower-end users we appear to be being pummelled by botnet owners testing their wares. Attacks are highly distributed, with Senderbase catching a fair chunk but CASE responding late (and I am checking that we are receiving our updates) if at all.

I have envelope sender DNS verification turned on for our mail flow policies covering our sender groups up to but not including our default group which starts at SBRS 0. Should I adjust our HAT to start the default group at a higher SBRS rating or enforce envelope sender verification for the default group? Aside from a HAT adjustment to a lower sender group, we're pretty much running as factory.

That brings me to my main question: how to block senders with no reverse DNS information? Am I correct in saying this is not an envelope sender verification failure as such?

I'd also like to do something about the more obvious dynamic hosts presenting themselves as or similar. I came up with the regex \D{0,X}\d{1,3}[-_]\d{1,3}[-_]\d{1,3}[-_]\d{1,3}\D{0,X} for use in a Remote IP / Hostname rule but am in two minds as to whether this is going to give me too many false positives. I'm going to have to guess a value for X, unless anyone has any suggestions.


Reverse DNS verification is

Reverse DNS verification is tricky.  I recently turned it on, and spent a couple of weeks sending mail to other sites saying "Hey! Set up reverse DNS!" to people who should know better...

And I came across several where it was done improperly... (ex. 2 ips sending mail as 1 dns name with only one of the IPs... so reverse wouldn't match forward lookup)

I did a couple of things that seem to have cut down on dirt.  SuspectList goes to 4, and DNS failures are included, this traffic gets throttled pretty hard.  I put a content filter in that SPF failures get dropped.

Sites with no spf info still comes in, because people don't seem to know how to do that either.






Thanks for the tip on SPF - I

Thanks for the tip on SPF - I might try it on the lower mail policies to begin with in case I get too many FPs. The general lack of reliable rDNS amongst senders comes as no surprise. I was more interested in cases where there is none at all.

CreatePlease to create content