Requesting guidance...
As you've been very helpful in the past, can I ask the best way forward in addressing this problem. In an attempt to reduce spam delivery to a local charity mail server, I added FEATURE(`require_rdns')dnl to the sendmail config. It did help. However, it also blocked some important clents as well... barnardos.org.nz - sends via 122-56-8-123.cid.global-gateway.net.nz logon.i.govt.nz - has no IP address ecan.govt.nz - sends via onyx.crc.govt.nz which has no IP address probably being the most important. How do you address this problem. I'm certain they all must have been repeatedly contacted? TIA for all ideas, Steve -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz MSN: steve(a)greengecko.co.nz Skype: sholdowa
On 7/09/2012 4:13 p.m., Steve Holdoway wrote:
As you've been very helpful in the past, can I ask the best way forward in addressing this problem.
In an attempt to reduce spam delivery to a local charity mail server, I added
FEATURE(`require_rdns')dnl
to the sendmail config. It did help. However, it also blocked some important clents as well...
barnardos.org.nz - sends via 122-56-8-123.cid.global-gateway.net.nz logon.i.govt.nz - has no IP address ecan.govt.nz - sends via onyx.crc.govt.nz which has no IP address
whitelist. Though those govts should have an public facing dns entry... but a quick search back though the archive would show that there are some big providers with helpdesks that fail that one, so again... white list. D
probably being the most important.
How do you address this problem. I'm certain they all must have been repeatedly contacted?
TIA for all ideas,
Steve
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699
On 07/09/12 16:13, Steve Holdoway wrote:
As you've been very helpful in the past, can I ask the best way forward in addressing this problem.
In an attempt to reduce spam delivery to a local charity mail server, I added
FEATURE(`require_rdns')dnl
to the sendmail config. It did help. However, it also blocked some important clents as well...
barnardos.org.nz - sends via 122-56-8-123.cid.global-gateway.net.nz logon.i.govt.nz - has no IP address ecan.govt.nz - sends via onyx.crc.govt.nz which has no IP address
probably being the most important.
How do you address this problem. I'm certain they all must have been repeatedly contacted?
TIA for all ideas
Hey Steve, That list of unmatched/missing rdns is the just the tip of the iceberg - especially with the government departments. Requiring reverse DNS is something we attempted years ago but the amount of legitimate e-mail that was blocked (especially a lot of those .govt.nz domains) meant it didn't last longer than a whole day. Even though it's the other guys doing it wrong it's hard to explain to customers that are quick to say "it works for ISP X, why not you guys?" Indeed, the "proper" solution would be to try and chase up those providers but it is hard to justify the time. Are you using greylisting? That still nets some good results still - stripping out the low hanging fruit before being processed by traditional spam filtering. - Damian -- Damian Kissick Actrix Networks Ph. 0800 ACTRIX #408 Mob. 027 251 1127 Fax. +64 4 801 5335 http://www.actrix.co.nz
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
On Fri, Sep 7, 2012 at 5:08 PM, Ewen McNeill
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. [...]
Back before I threw up my hands and shifted my mail to Google, I ran qpsmtpd (perl MTA) with a bunch of custom modules, in front of postfix. My "secret sauce" which reduced my whitelist size a bit was what I called the "geeks on DSL" rule, although it also allowed mail from ccdhb.org.nz and other similar organisations. If you failed the "no reverse DNS" or "dynamic IP range" rules, I'd still allow your mail if the source IP was in the same /24 as any of the domain's MX records, A records, or www. A/CNAME/etc record. This worked surprisingly well, but I still had to maintain a growing whitelist.
Are you using greylisting? That still nets some good results still [...] I'd echo this too. ...
I found users were too used to email being instantaneous for greylisting to be useful -- I'd get too many "email is broken" complaints. Also the people I was contracting for ran a bizzare MacOS based email server that refused to retry sending emails, and I did quite like getting paid... donald
On Fri, 7 Sep 2012, Steve Holdoway wrote:
As you've been very helpful in the past, can I ask the best way forward in addressing this problem.
In an attempt to reduce spam delivery to a local charity mail server, I added
FEATURE(`require_rdns')dnl
My advice is don't try to devise rules for spam blocking yourself, as you've found even a simple idea like requiring reverse DNS will have false positives. There are plenty of other "simple" solutions that will also come back to bite you [1]. Either outsource your filtering or install something like Spamassassin which comes with it's own build-in rules enabled and tuned. [1] - "Voodoo spam filtering" is a phrase I like. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
On Fri, 2012-09-07 at 17:25 +1200, Simon Lyall wrote:
On Fri, 7 Sep 2012, Steve Holdoway wrote:
As you've been very helpful in the past, can I ask the best way forward in addressing this problem.
In an attempt to reduce spam delivery to a local charity mail server, I added
FEATURE(`require_rdns')dnl
My advice is don't try to devise rules for spam blocking yourself, as you've found even a simple idea like requiring reverse DNS will have false positives. There are plenty of other "simple" solutions that will also come back to bite you [1].
Either outsource your filtering or install something like Spamassassin which comes with it's own build-in rules enabled and tuned.
[1] - "Voodoo spam filtering" is a phrase I like.
For incoming mail, I'm using services from SpamHaus - zen list in sendmail and drop list via iptables updated daily - and greylisting. I hate spamassassin with a vengeance for exactly the reason you mentioned above - creating your own rules = imperfect + job for life. However, I really don't consider RDNS to be in that category: isn't it in the RFC? Ugh I just checked: 1912 Section 2.1... 'For every IP address, there should be a matching PTR record in the in-addr.arpa domain.' should, not must. Missed that first time around. Bugger. I cannot outsource this mail due to its sensitive nature, backed up by the board's decision. This also negates the use of naughty word filters as well... Cheers, Steve -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz MSN: steve(a)greengecko.co.nz Skype: sholdowa
On 7/09/2012, at 4:13 PM, Steve Holdoway
As you've been very helpful in the past, can I ask the best way forward in addressing this problem.
In an attempt to reduce spam delivery to a local charity mail server, I added
FEATURE(`require_rdns')dnl
to the sendmail config. It did help. However, it also blocked some important clents as well...
barnardos.org.nz - sends via 122-56-8-123.cid.global-gateway.net.nz logon.i.govt.nz - has no IP address ecan.govt.nz - sends via onyx.crc.govt.nz which has no IP address
probably being the most important.
How do you address this problem. I'm certain they all must have been repeatedly contacted?
I ran a HELO/EHLO verification test once and contacted lots of people who failed it. The results made me decide to not do it again: http://blog.nominet.org.uk/tech/2005/08/06/incorrect-heloehlo-information-is... Jay
TIA for all ideas,
Steve -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz MSN: steve(a)greengecko.co.nz Skype: sholdowa _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley
participants (8)
-
Damian Kissick -
Don Gould -
Donald Gordon -
Ewen McNeill -
Jay Daley -
Nathan Ward -
Simon Lyall -
Steve Holdoway