Does Anyone Use "Strict RDNS Checks"?

Anyway, does anyone else actually use the "strict RDNS checks" option?  Should I just give up and not use that option?  I'm sick of constantly having to explain this situation and/or create exceptions for these people.

Don't use it in production environments (advice from the field)...this is  neverending battle with other IT guys and your users complaining about e-mails that have never been received.

Don't use it in production environments (advice from the field)...this is  neverending battle with other IT guys and your users complaining about e-mails that have never been received.

Thanks you guys. I guess I'll disable that option. I just can't get over how many idiotic admins there are out there.

We receive about 5,000 emails per day, 60% of which the UTM considers spam. I know none of the anti-spam measures we implement are 100% foolproof but now I have to disable a useful option in that fight just to accommodate a bunch of morons. Stupid, stupid, stupid.  Okay, sorry, end of rant...

Don't use it in production environments (advice from the field)...this is  neverending battle with other IT guys and your users complaining about e-mails that have never been received.

Thanks you guys. I guess I'll disable that option. I just can't get over how many idiotic admins there are out there.

We receive about 5,000 emails per day, 60% of which the UTM considers spam. I know none of the anti-spam measures we implement are 100% foolproof but now I have to disable a useful option in that fight just to accommodate a bunch of morons. Stupid, stupid, stupid.  Okay, sorry, end of rant...

Thanks you guys. I guess I'll disable that option. I just can't get over how many idiotic admins there are out there.

We receive about 5,000 emails per day, 60% of which the UTM considers spam. I know none of the anti-spam measures we implement are 100% foolproof but now I have to disable a useful option in that fight just to accommodate a bunch of morons. Stupid, stupid, stupid.  Okay, sorry, end of rant...

I would leave it on as it is the primary means of spam blocking as most spammers don't setup rdns either.  Check your smtp logs and send those back to the affected organizations.  Also you can whiltelist those domains that run afoul of this i would not turn rdns off.

I would leave it on as it is the primary means of spam blocking as most spammers don't setup rdns either.  Check your smtp logs and send those back to the affected organizations.  Also you can whiltelist those domains that run afoul of this i would not turn rdns off.

I would leave RDNS on as a spam filter too.  It is extremely rare that legit senders have RDNS issues.  It's pretty fundamental and basic that any sending email server or ISP should at least get their RDNS right.  In the business environments I work in, I have only vary rarely had a problem with it.  Definitely not nearly enough to even begin to consider not using it.

BTW, I haven't had any problem explaining to end users that the email server of the guy sending them email with invalid RDNS info is screwing up on one the basic rules about sending email, and that the other side needs to fix it.  I also offer to discuss with the other sides tech if they'd like.  I also offer to set an exception for the other side.  Nonetheless, it's a very rare problem.

I would leave RDNS on as a spam filter too.  It is extremely rare that legit senders have RDNS issues.  It's pretty fundamental and basic that any sending email server or ISP should at least get their RDNS right.  In the business environments I work in, I have only vary rarely had a problem with it.  Definitely not nearly enough to even begin to consider not using it.

RDNS can't always be managed by a company running their own email servers. Case in point is our incumbent regional ISP (TELUS Communications). They offer two levels of ADSL for business. The top tier service, which we use at work, is the good stuff, SLA's, true static IP's, DNS & RDNS for the netblock so easy to run public facing services from.

The base level tier isn't much more then a regular consumer DSL with optional "static" IP's (long lease DHCP), firewall changes to permit public facing services (the consumer service has ingress filtering on common ports) and TOS changes to allow said servers. The service however has no option to change RDNS entries so one has to setup the email server to advertise TELUS' preconfigured RDNS entries.

Thankfully most users who are using the second one don't run their own servers in house, and those that do where I've had consulting engagements, I've been able to switch over to something better liked hosted exchange.

I would leave RDNS on as a spam filter too. It is extremely rare that legit senders have RDNS issues. It's pretty fundamental and basic that any sending email server or ISP should at least get their RDNS right. In the business environments I work in, I have only vary rarely had a problem with it. Definitely not nearly enough to even begin to consider not using it.

I agree, it is very fundamental and basic; hence my complete disappointment in these "experts" and hosting services that set this stuff up for small office environments. Unfortunately, it's not rare for us. I think I've been asked about these bounces and how I can fix it about two dozen times in the last two weeks.

RDNS can't always be managed by a company running their own email servers. Case in point is our incumbent regional ISP (TELUS Communications). They offer two levels of ADSL for business. The top tier service, which we use at work, is the good stuff, SLA's, true static IP's, DNS & RDNS for the netblock so easy to run public facing services from.

Exactly. We deal with a lot of vendors and law offices (unfortunately) that have their email hosted by some random hosting service but they insist on sending mail from a host in their office running on a cable modem. Because that outgoing host doesn't match their published MX records, guess what. So, first, try explaining that to a lawyer who already knows everything and can't be told he/she isn't doing something correctly and who doesn't really specialize in anything except wearing people down until they finally just give in and say screw it, have it your way. Well, in my case, creating exceptions for all of these people is unacceptable and creates too much administrative overhead. Just set your crap up correctly in the first place and it won't be an issue!

My favorite so far has been:

Fortunately my computer nerd is coming to town for a visit this weekend, so he will have something to do.  I have forwarded this and the previous email to him.  He has not heard anything like this, but is doing research.

My initial response to that was "Find yourself a new computer nerd".