On 2012-09-07 16:35 , Damian Kissick wrote:
On 07/09/12 16:13, Steve Holdoway wrote:
FEATURE(`require_rdns')dnl [...] to the sendmail config. It did help. However, it also blocked some important clents as well... [organisations that should know better]
That list of unmatched/missing rdns is the just the tip of the iceberg - especially with the government departments. Indeed, the "proper" solution would be to try and chase up those providers but it is hard to justify the time.
To echo this, it appears to be basically impossible to persuade a lot of organisations these days to put proper (eg, matching!) reverse/forward DNS in for their mail servers. NZ Government departments seem particularly resistant, but back when I was actually trying I even had a NZ ISP refuse to do so for customer {colo|vm} hosts (at least one claiming they didn't want to put in matching reverse/forward DNS as an anti-spam measure; no idea how that works when the customer is trying to use their server as a MTA...). So I gave up trying to persuade anyone to change the DNS for their mail servers years ago, and resorted to whitelisting. It's barely tolerable effort for a personal mail server, and then only because I usually know when I'm expecting mail and can read the mail server logs if it doesn't arrive. I'm sure it's far too much like hard work whitelisting all the brokenness for a mail server run for other people.
Are you using greylisting? That still nets some good results still [...]
I'd echo this too. If you can live with mail being delayed an arbitrary amount of time (you have to wait for the other side to feel like retrying, irrespective of what time you set as a minimum delay at your end), it still sounds like it's pretty effective. If I were setting my personal mail server up again, I'd probably try to do "RDNS not sane, then greylist" -- so that at least the poorly configured mail servers would get through eventually, but well set up mail servers didn't see a delay. Ewen