Weblog entry #118 for simonw
See all weblog entries made by simonw.
#118
Additional Spam Filtering Techniques for Admins
Posted by simonw on Wed 13 Dec 2006 at 19:15
Spent part of the afternoon checking out various antispam techniques I've seen commented on elsewhere.
BLACKLIST: bogusmx.rfc-ignorant.org
Lists domains with misconfigured MX records. This includes things like MX records that point to 127.0.0.1, which look valid, but don't work. I looked at using this as an absolute block in Postfix on the envelope senders domain.
Initial investigations suggest we would have rejected a few genuine email on each of our servers using this test today. Three domains would have been affected, in two of these three cases the domains no longer had any errors with their MX records, and they were removed when I checked at rfc-ignorant.org, one domain had one non-resolving MX, but the other worked.
I also noted that yahoo.com.mx no longer had obvious errors, and that was removed from the list when I clicked on the details button.
The investigation also suggested we would have blocked only one additional spam. So the marginal value over postgrey and SBL-XBL was much less than the problems it would likely introduce. I'll file this one under "use it when greylisting fails, or where greylisting isn't available".
Reject SMTP clients with no reverse DNS
Complete non-starter, Eclipse Internet don't provide reverse DNS, so a large number of our clients correspondents don't have reverse DNS for their corporate email servers.
Reject clients based on HELO/EHLO strings
Looked at rejection of SMTP clients using our servers own IP addresses, or server names, as part of the HELO/EHLO greeting. This test hasn't yet produced a false positive, but it also didn't add anything to the current filtering. Presumably we can conclude these bots don't retry, so don't get passed greylisting, or are already in the CBL.
This test is showing some potential, so I'll look at it more closely and also experiment with additional HELO patterns ("localhost" looks a promising pattern to investigate further).
I had expected that the HELO test would be the most promising, but it was nice to test these ideas against real data, to see how effective or otherwise they would be.
BLACKLIST: bogusmx.rfc-ignorant.org
Lists domains with misconfigured MX records. This includes things like MX records that point to 127.0.0.1, which look valid, but don't work. I looked at using this as an absolute block in Postfix on the envelope senders domain.
Initial investigations suggest we would have rejected a few genuine email on each of our servers using this test today. Three domains would have been affected, in two of these three cases the domains no longer had any errors with their MX records, and they were removed when I checked at rfc-ignorant.org, one domain had one non-resolving MX, but the other worked.
I also noted that yahoo.com.mx no longer had obvious errors, and that was removed from the list when I clicked on the details button.
The investigation also suggested we would have blocked only one additional spam. So the marginal value over postgrey and SBL-XBL was much less than the problems it would likely introduce. I'll file this one under "use it when greylisting fails, or where greylisting isn't available".
Reject SMTP clients with no reverse DNS
Complete non-starter, Eclipse Internet don't provide reverse DNS, so a large number of our clients correspondents don't have reverse DNS for their corporate email servers.
Reject clients based on HELO/EHLO strings
Looked at rejection of SMTP clients using our servers own IP addresses, or server names, as part of the HELO/EHLO greeting. This test hasn't yet produced a false positive, but it also didn't add anything to the current filtering. Presumably we can conclude these bots don't retry, so don't get passed greylisting, or are already in the CBL.
This test is showing some potential, so I'll look at it more closely and also experiment with additional HELO patterns ("localhost" looks a promising pattern to investigate further).
I had expected that the HELO test would be the most promising, but it was nice to test these ideas against real data, to see how effective or otherwise they would be.
Comments on this Entry
With Postfix I'm using
reject_non_fqdn_hostname
which seems to catch a fair few bot-type sources before they get into the RBL.
I've got check_helo_access setup with things like localhost, our own hostname etc, but the fqdn restriction seems to bite first.
reject_non_fqdn_hostname
which seems to catch a fair few bot-type sources before they get into the RBL.
I've got check_helo_access setup with things like localhost, our own hostname etc, but the fqdn restriction seems to bite first.
[ Parent | Reply to this comment ]
I'm slightly less clear on the Eclipse comment.
I found some genuine clients without reverse lookup using IP addresses I thought (well whois did) were with Eclipse Internet, but when I revisited it today I couldn't find the any Eclipse space without reverse lookup, and they provide a webpage detailing how customers can ask for customer reverse lookup.
I better keep better notes next time, perhaps I cut and pasted the wrong address or something similar.
I found some genuine clients without reverse lookup using IP addresses I thought (well whois did) were with Eclipse Internet, but when I revisited it today I couldn't find the any Eclipse space without reverse lookup, and they provide a webpage detailing how customers can ask for customer reverse lookup.
I better keep better notes next time, perhaps I cut and pasted the wrong address or something similar.
[ Parent | Reply to this comment ]