Using nolisting to reduce spam
Yesterday, I came across the concept of 'nolisting' as a technique for reducing the volume of inbound spam. It wasn't something I had previously come across so have done some reading on the topic. http://nolisting.org as a starting point. For such a simple technique, I was surprised by its impact. Simply speaking, the idea is to use a primary MX that doesn't listen on port 25 but simply rejects the connection. Well behaved MTAs will all try the secondary MX(es) and delivery will occur. Many spambots only try the primary so there is an immediately benefit, less inbound to check in other ways and a consequential increase in the available resources on the mail server(s). I set it up on one domain and behavior seems to be exactly as described. My reading suggests that there is no negative impact on legitimate mail and no noticeable additional latency in delivery as the switch from the primary to secondary on a reject is almost instantaneous. I was wondering whether anyone else has had any experience with this technique and if so whether the claim that it has no negative impact is true. Also, if people haven't heard of it, it may be something people might want to look at as another weapon in the anti-spam war. Glen.
On 2008-01-15 10:43, Glen Eustace wrote:
Yesterday, I came across the concept of 'nolisting' as a technique for reducing the volume of inbound spam. It wasn't something I had previously come across so have done some reading on the topic. http://nolisting.org as a starting point.
For such a simple technique, I was surprised by its impact.
Simply speaking, the idea is to use a primary MX that doesn't listen on port 25 but simply rejects the connection. Well behaved MTAs will all try the secondary MX(es) and delivery will occur. Many spambots only try the primary so there is an immediately benefit, less inbound to check in other ways and a consequential increase in the available resources on the mail server(s).
But there's a pretty simple and obvious way to make spambots immune to this, without needing to conform to RFC 2821. I'd expect the bots to be updated fairly soon, so the respite will probably be short. Greylisting is a lot harder to beat. Brian
I set it up on one domain and behavior seems to be exactly as described. My reading suggests that there is no negative impact on legitimate mail and no noticeable additional latency in delivery as the switch from the primary to secondary on a reject is almost instantaneous.
I was wondering whether anyone else has had any experience with this technique and if so whether the claim that it has no negative impact is true. Also, if people haven't heard of it, it may be something people might want to look at as another weapon in the anti-spam war.
Glen.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Paradise did this by pointing the first MX to pop.paradise.net.nz which was not an MX server, it would then have the real MX listed as second priority. I beleive it would releave some spam bots, but from what I can tell (running greylist with 2 MX's) the spambots often go for the secondary MX first now days. The reason for this, generally a secondary MX would be your upstreams mail server, they would not have the same spam protection as your running, they would queue the email and deliver it to you, your mail server would have learnt to trust this host. Doubt it would stop much in my own opinion. Cheers B
Yesterday, I came across the concept of 'nolisting' as a technique for reducing the volume of inbound spam. It wasn't something I had previously come across so have done some reading on the topic. http://nolisting.org as a starting point.
For such a simple technique, I was surprised by its impact.
Simply speaking, the idea is to use a primary MX that doesn't listen on port 25 but simply rejects the connection. Well behaved MTAs will all try the secondary MX(es) and delivery will occur. Many spambots only try the primary so there is an immediately benefit, less inbound to check in other ways and a consequential increase in the available resources on the mail server(s).
I set it up on one domain and behavior seems to be exactly as described. My reading suggests that there is no negative impact on legitimate mail and no noticeable additional latency in delivery as the switch from the primary to secondary on a reject is almost instantaneous.
I was wondering whether anyone else has had any experience with this technique and if so whether the claim that it has no negative impact is true. Also, if people haven't heard of it, it may be something people might want to look at as another weapon in the anti-spam war.
Glen.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
From my observations we get more spam delivered to our secondary mail servers. To combat this we have made SPF very aggressive on our secondary mail servers, this has drastically reduced our spam intake. The danger of course is if our primary mail server goes down that real email will be rejected by the secondaries. So far however the benefits have outweighed the risks for us.
Potentially load balancing our primary mail server (or 2 MX records with the same priority sending mail to mail servers configured with the same SPF settings) would mitigate the risk further. -----Original Message----- From: Barry Murphy [mailto:barry(a)unix.co.nz] Sent: Tuesday, 15 January 2008 11:06 a.m. To: Glen Eustace Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Using nolisting to reduce spam Paradise did this by pointing the first MX to pop.paradise.net.nz which was not an MX server, it would then have the real MX listed as second priority. I beleive it would releave some spam bots, but from what I can tell (running greylist with 2 MX's) the spambots often go for the secondary MX first now days. The reason for this, generally a secondary MX would be your upstreams mail server, they would not have the same spam protection as your running, they would queue the email and deliver it to you, your mail server would have learnt to trust this host. Doubt it would stop much in my own opinion. Cheers B
Yesterday, I came across the concept of 'nolisting' as a technique for reducing the volume of inbound spam. It wasn't something I had previously come across so have done some reading on the topic. http://nolisting.org as a starting point.
For such a simple technique, I was surprised by its impact.
Simply speaking, the idea is to use a primary MX that doesn't listen on port 25 but simply rejects the connection. Well behaved MTAs will all try the secondary MX(es) and delivery will occur. Many spambots only try the primary so there is an immediately benefit, less inbound to check in other ways and a consequential increase in the available resources on the mail server(s).
I set it up on one domain and behavior seems to be exactly as described. My reading suggests that there is no negative impact on legitimate mail and no noticeable additional latency in delivery as the switch from the primary to secondary on a reject is almost instantaneous.
I was wondering whether anyone else has had any experience with this technique and if so whether the claim that it has no negative impact is true. Also, if people haven't heard of it, it may be something people might want to look at as another weapon in the anti-spam war.
Glen.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
i have seen much more spam on secondary mail servers too. recently, i quizzed a guy i know at sendmail.com about it. he told me that the current thinking amongst mail professionals (caveat: his opinion) is to not use secondaries. my personal secondary mx server saw nothing but spam and tons of it. the spammers continually use new techniques responding to current conditions so ymmv. Damon Coursey wrote:
From my observations we get more spam delivered to our secondary mail servers
-- Mark Smith E mark.smith(a)endace.com P +64 7 834 6227 W http://www.endace.com Endace Technologies, Limited 85 Alexandra Street Hamilton Endace delivers absolute performance for monitoring and intervention over the widest range of network types and software applications.
Yesterday, I came across the concept of 'nolisting' as a technique for reducing the volume of inbound spam. It wasn't something I had previously come across so have done some reading on the topic. http://nolisting.org as a starting point.
For such a simple technique, I was surprised by its impact.
Simply speaking, the idea is to use a primary MX that doesn't listen on port 25 but simply rejects the connection. Well behaved MTAs will all try the secondary MX(es) and delivery will occur. Many spambots only try the primary so there is an immediately benefit, less inbound to check in other ways and a consequential increase in the available resources on the mail server(s).
I set it up on one domain and behavior seems to be exactly as described. My reading suggests that there is no negative impact on legitimate mail and no noticeable additional latency in delivery as
People have been avoiding backup MX entries for this very reason for a few years now. However, if some people are getting good results with these methods, has anybody tried having three MX entries with the middle one being the live one? Regards, Chris Curtis -----Original Message----- From: Barry Murphy [mailto:barry(a)unix.co.nz] Sent: Tuesday, 15 January 2008 11:06 a.m. To: Glen Eustace Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Using nolisting to reduce spam Paradise did this by pointing the first MX to pop.paradise.net.nz which was not an MX server, it would then have the real MX listed as second priority. I beleive it would releave some spam bots, but from what I can tell (running greylist with 2 MX's) the spambots often go for the secondary MX first now days. The reason for this, generally a secondary MX would be your upstreams mail server, they would not have the same spam protection as your running, they would queue the email and deliver it to you, your mail server would have learnt to trust this host. Doubt it would stop much in my own opinion. Cheers B the
switch from the primary to secondary on a reject is almost instantaneous.
I was wondering whether anyone else has had any experience with this technique and if so whether the claim that it has no negative impact is true. Also, if people haven't heard of it, it may be something people might want to look at as another weapon in the anti-spam war.
Glen.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Chris Curtis wrote:
However, if some people are getting good results with these methods, has anybody tried having three MX entries with the middle one being the live one?
....
Doubt it would stop much in my own opinion.
Cheers B
I am not in a position to dispute the empirical evidence presented at http://nolisting.org, but it would seem to imply that there are still a large number of bots that are still just using the primary MX. My observations of the domain I have applied this to are that it is definitely stopping connections. I am not assuming that it is a silver bullet, it quite clearly is not. But with 98% of the inbound on our email servers last month being spam, any reduction in 'cr*p' would seem to be worth it, particularly as this one doesn't cost anything and is reasonably easy to implement. BUT, I am a little anxious as to whether there is a down side. Glen.
However, if some people are getting good results with these methods, has anybody tried having three MX entries with the middle one being the
I presume you do have a spam product doing a good job? Personally I am more concerned with getting the stuff blocked than reducing incoming traffic, as traffic is cheap these days. Also, spam messages are typically small, and therefore 90% of messages doesn't equate to 90% of traffic. We've got a product here doing an excellent job. 1 or 2 a month are slipping through to my inbox, and I've never had a false positive I know about. This said, I don't deal with enterprise size deployments, so therefore don't have to watch every bit of bandwidth like a hawk. Chris Curtis -----Original Message----- From: Glen Eustace [mailto:geustace(a)godzone.net.nz] Sent: Tuesday, 15 January 2008 11:24 a.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Using nolisting to reduce spam Chris Curtis wrote: live
one?
....
Doubt it would stop much in my own opinion.
Cheers B
I am not in a position to dispute the empirical evidence presented at http://nolisting.org, but it would seem to imply that there are still a large number of bots that are still just using the primary MX. My observations of the domain I have applied this to are that it is definitely stopping connections. I am not assuming that it is a silver bullet, it quite clearly is not. But with 98% of the inbound on our email servers last month being spam, any reduction in 'cr*p' would seem to be worth it, particularly as this one doesn't cost anything and is reasonably easy to implement. BUT, I am a little anxious as to whether there is a down side. Glen. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On 15/01/2008, at 11:40 AM, Chris Curtis wrote:
I presume you do have a spam product doing a good job?
Personally I am more concerned with getting the stuff blocked than reducing incoming traffic, as traffic is cheap these days. Also, spam messages are typically small, and therefore 90% of messages doesn't equate to 90% of traffic. We've got a product here doing an excellent job. 1 or 2 a month are slipping through to my inbox, and I've never had a false positive I know about.
This said, I don't deal with enterprise size deployments, so therefore don't have to watch every bit of bandwidth like a hawk.
It is not the bandwidth that we worry about, it is the processing capacity. Currently we have three grunty boxes handing incoming mail and doing anti-spam processing. With out grey listing we would need at least another one and without spam at all we could get away with two much smaller machines. Our current worry is that spammers will suddenly decide that greylisting is taking too much of a toll on their operations and rewrite their senders to include some crude queueing. Then we would have to handle nearly double the number of incoming messages. I believe that this could happen quite quickly and we would be left with heavily overloaded incoming mail servers as it takes *at least* a month from order to deployment of new hardware. More realistically two months as these are not off the shelf components. Russell
Russell Fulton wrote:
It is not the bandwidth that we worry about, it is the processing capacity. Currently we have three grunty boxes handing incoming mail and doing anti-spam processing. With out grey listing we would need at least another one and without spam at all we could get away with two much smaller machines.
I concur.
Our current worry is that spammers will suddenly decide that greylisting is taking too much of a toll on their operations and rewrite their senders to include some crude queueing. Then we would have to handle nearly double the number of incoming messages. I believe that this could happen quite quickly and we would be left with heavily overloaded incoming mail servers as it takes *at least* a month from order to deployment of new hardware. More realistically two months as these are not off the shelf components.
I have had 'nolisting' turned on for just 24 hours, a single day isn't a good sample but if it is indicative, then I am going to be quite pleased with the result. Total inbound rejected by the MTAs over the last few months has been 98%. Yesterday, this dropped to 78%. That is a lot of DNS lookups that didn't need to be done, a lot of users that didn't need to be checked and a lot of content that didn't need to be examined and hence a lot of resource I just got back. I am not sure whether there will be any difference between an MTA handling hundreds of domains as is the case with my trial or one that handles only one. But if yesterday was anything to go by, I will be recommending we turn on 'nolisting' at Massey University as well! Glen. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen and Rosanne Eustace GodZone Internet Services, a division of AGRE Enterprises Ltd. P.O. Box 8020, Palmerston North, New Zealand 4446. Ph: +64 6 357 8168, Fax +64 6 357 8165, Mob: +64 21 424 015 http://www.godzone.net.nz "A Ministry specialising in providing low-cost Internet Services to NZ Christian Churches, Ministries and Organisations."
Our current worry is that spammers will suddenly decide that greylisting is taking too much of a toll on their operations and rewrite their senders to include some crude queueing. Then we would have to handle nearly double the number of incoming messages. I believe that this could happen quite quickly and we would be left with heavily overloaded incoming mail servers as it takes *at least* a month from order to deployment of new hardware. More realistically two months as these are not off the shelf components.
I have had 'nolisting' turned on for just 24 hours, a single day isn't a good sample but if it is indicative, then I am going to be quite pleased with the result. Total inbound rejected by the MTAs over the last few months has been 98%. Yesterday, this dropped to 78%. That is a lot of DNS lookups that didn't need to be done, a lot of users that didn't need to be checked and a lot of content that didn't need to be examined and hence a lot of resource I just got back.
I am not sure whether there will be any difference between an MTA handling hundreds of domains as is the case with my trial or one that handles only one. But if yesterday was anything to go by, I will be recommending we turn on 'nolisting' at Massey University as well!
A good result. The thing with spam that we all know, though, is there is no 'golden bullet' - all of these measures are merely interim mitigators, we should all expect the spammers to evolve and develop means of defeating these methods. (In other words, people should be prepared for the increases in load, etc, that are inevitable over time, and gear their boxes and upgrade plans accordingly.) Mark.
Last month when I raised this issue, I said that I would collect some stats on whether the use of 'nolisting' was of any significant benefit. These numbers were collected from the first 18 days of Jan 2008 and the same period in Feb 2008. The numbers are as reported by logwatch's postfix analysis of the mail logs on the two servers. Accepted Rejected Total Primary - Jan 42542(2.49%) 1663404(97.51%) 1705946 Secondary - Jan 33479(7%) 444991(93%) 478770 Primary - Feb 147858(39.9%) 222478(60.07%) 370336 Secondary - Feb 26767(8.4%) 293800(91.65%) 320567 There was a significantly higher proportion of mail accepted by the primary in Feb but that could be that many of our clients might have been on holiday in January. I believe that the large reduction in the mail being rejected by postfix on the primary MX is a pretty good indicator that there still are a large number of spambots that only try the primary MX. Nolisting is NOT the cure for spam but as another layer in a multi-layered defense, it seems to be pretty effective. But as always YMMV. I am also aware that as a part of any solution it may not have a long lifetime but for the moment we are going to leave it turned on. Glen.
the spambots often go for the secondary MX first now days.
Spam bots that do this will go for your lowest priority machine, this is because it is percieved to potentially be less well maintained, less up to date and potentially have more flaws in it's antispam antivirus that will allow through more spam. A simple solution would be to have your live server in between two nolist mx records. I know of email admins that have their primary MX the same as their lowest priority MX for this reason. All the best Greg Soffe Mail Administrator - Network Analyst Network Security Operations -----Original Message----- From: Barry Murphy [mailto:barry(a)unix.co.nz] Sent: Tuesday, 15 January 2008 11:06 a.m. To: Glen Eustace Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Using nolisting to reduce spam Paradise did this by pointing the first MX to pop.paradise.net.nz which was not an MX server, it would then have the real MX listed as second priority. I beleive it would releave some spam bots, but from what I can tell (running greylist with 2 MX's) the spambots often go for the secondary MX first now days. The reason for this, generally a secondary MX would be your upstreams mail server, they would not have the same spam protection as your running, they would queue the email and deliver it to you, your mail server would have learnt to trust this host. Doubt it would stop much in my own opinion. Cheers B
I haven't tried nolisting but would assume it would have the same issues as greylisting, in that there are some large organisations who run non compliant mail systems, and mail from them would fail. Last time I looked at the list of organistaions I didn't feel that I would be getting mail from them. I now can't find the list... that's the interweb for you... Here's a list of non-compliant mail servers (from http://projects.puremagic.com/greylisting/) * Novell Groupwise 6.0 - Confirmation Link * ISMail 1.7.1 and prior - Non-compliant. Reported as fixed in ISMail 1.7.4 and later. * InterMail 4.0 - Reported * Kerio MailServer 5.0.5 - Reported So the ability to whitelist is important, but you couldn't whitelist with nolisting. But I despise spam so much, as it eats our mail servers and eats our bandwidth, that I'd be happy to talk with organisations with these mail server and tell them that they really need to 'get with the program'. But only with our own mail. I'm not so sure about the realities of implementing this across thousands of ISP customers and trying to get them to understand why we're not allowing email from their mum to be delivered. And a pile of spam now get delivered to secondary MXs first as these often don't have synchronised user lists and often accept mail without checking much, but are trusted hosts from the primary's point of view. But it's worth a go. Might get some reprieve for a few months. Regards, Gerard On 15/01/2008 10:43 a.m., Glen Eustace wrote:
Yesterday, I came across the concept of 'nolisting' as a technique for reducing the volume of inbound spam. It wasn't something I had previously come across so have done some reading on the topic. http://nolisting.org as a starting point.
For such a simple technique, I was surprised by its impact.
Simply speaking, the idea is to use a primary MX that doesn't listen on port 25 but simply rejects the connection. Well behaved MTAs will all try the secondary MX(es) and delivery will occur. Many spambots only try the primary so there is an immediately benefit, less inbound to check in other ways and a consequential increase in the available resources on the mail server(s).
I set it up on one domain and behavior seems to be exactly as described. My reading suggests that there is no negative impact on legitimate mail and no noticeable additional latency in delivery as the switch from the primary to secondary on a reject is almost instantaneous.
I was wondering whether anyone else has had any experience with this technique and if so whether the claim that it has no negative impact is true. Also, if people haven't heard of it, it may be something people might want to look at as another weapon in the anti-spam war.
Glen.
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Netspace Services Limited http://www.netspace.net.nz Phone +64 4 917 8098 Mobile +64 21 246 2266 Level One, 220 Thorndon Quay, Thorndon PO Box 12-082, Thorndon, Wellington 6004, New Zealand
On 15/01/2008, at 11:23 AM, Gerard Creamer wrote:
eats our bandwidth
And if you're an access ISP with a mail service, you're going to be receiving that spam email, and not being able to charge your end users for downloading it :-) I'm not sure that bandwidth is a reason for spam filtering, unless you're a really big mail provider or something. "Because users want it" is a much better reason. Does anyone have actual stats of what sort of percentage of their traffic is spam? I don't really have any easy way to get that right now, unless I make my mail server output message size stats in to log files, or something. I'm curious as to whether anyone else has an easy way to get it that I'm missing. -- Nathan Ward
Does anyone have actual stats of what sort of percentage of their traffic is spam? I don't really have any easy way to get that right now, unless I make my mail server output message size stats in to log files, or something. I'm curious as to whether anyone else has an easy way to get it that I'm missing.
Measured by attempted messages (which admittedly isn't exactly byte volume), we reject roughly 97% ~ 99%. On a really good day this can drop to 94%; on a bad day it has topped 99.2%. And that doesn't count the false negatives; I can't give you an exact rate for those other than to say "small". -Martin
Nathan Ward wrote:
On 15/01/2008, at 11:23 AM, Gerard Creamer wrote:
eats our bandwidth
And if you're an access ISP with a mail service, you're going to be receiving that spam email, and not being able to charge your end users for downloading it :-)
I'm not sure that bandwidth is a reason for spam filtering, unless you're a really big mail provider or something.
"Because users want it" is a much better reason.
Does anyone have actual stats of what sort of percentage of their traffic is spam? I don't really have any easy way to get that right now, unless I make my mail server output message size stats in to log files, or something. I'm curious as to whether anyone else has an easy way to get it that I'm missing.
I know I'm small fry by many of your standards but here are the local figures for Jan 15th 2008. (filters in order) RBL-Blocked 590 NX-rDNS 506 Other-Reject 385 SPF-Blocked 13 Viral 0 Spam-Trap Accepted 564 Delivered Mail 1533 Forwarded Mail 73 So spam, (blocked+trapped) is 1606/2058 -> 78% of all email yesterday. Seems to have been a slow day with only 564 trapped. Most months the traps hits 40K+ over the whole period. Based on random enquiries of customers when they contact, I'd estimate somewhere around 1% gets delivered when it should not. AYJ Treehouse Networks Ltd.
We use nolisting, greylisting and spamassassin. When we implemented greylisting we found that our processed message load dropped from ~40,000 messages per day to ~20,000 messages per day. A while later we implemented nolisting and our greylisting load dropped by virtually the same amount. I haven't done too much log trolling because i'm lazy but looking at the stats for the last week tell the following story: Total Messages Processed: 146373 Total Message Size: 2445MB Spam Messages Identified: 89108 (61%) Spam Data Volume: 552MB (26%) AFAIK greylisting and nolisting do work as our spam volume percentages were closer to 95% beforehand. Kind Regards Tim Price Technical Manager thepacific.net Ltd tim(a)tpnet.co.nz +64 3 5439095 TreeNet Admin wrote:
Nathan Ward wrote:
On 15/01/2008, at 11:23 AM, Gerard Creamer wrote:
eats our bandwidth
And if you're an access ISP with a mail service, you're going to be receiving that spam email, and not being able to charge your end users for downloading it :-)
I'm not sure that bandwidth is a reason for spam filtering, unless you're a really big mail provider or something.
"Because users want it" is a much better reason.
Does anyone have actual stats of what sort of percentage of their traffic is spam? I don't really have any easy way to get that right now, unless I make my mail server output message size stats in to log files, or something. I'm curious as to whether anyone else has an easy way to get it that I'm missing.
I know I'm small fry by many of your standards but here are the local figures for Jan 15th 2008.
(filters in order) RBL-Blocked 590 NX-rDNS 506 Other-Reject 385 SPF-Blocked 13 Viral 0
Spam-Trap Accepted 564 Delivered Mail 1533 Forwarded Mail 73
So spam, (blocked+trapped) is 1606/2058 -> 78% of all email yesterday. Seems to have been a slow day with only 564 trapped. Most months the traps hits 40K+ over the whole period.
Based on random enquiries of customers when they contact, I'd estimate somewhere around 1% gets delivered when it should not.
AYJ Treehouse Networks Ltd. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
Tim Price wrote:
We use nolisting, greylisting and spamassassin.
When we implemented greylisting we found that our processed message load dropped from ~40,000 messages per day to ~20,000 messages per day. A while later we implemented nolisting and our greylisting load dropped by virtually the same amount. I haven't done too much log trolling because i'm lazy but looking at the stats for the last week tell the following story:
Total Messages Processed: 146373 Total Message Size: 2445MB Spam Messages Identified: 89108 (61%) Spam Data Volume: 552MB (26%)
AFAIK greylisting and nolisting do work as our spam volume percentages were closer to 95% beforehand.
Thanks Tim. A number of people it would seem have not read the theory behind nolisting and seem to have assumed that it will increase network activity and traffic. Provided that the non-functional MX sends a TCP reset, this is not the case. There is a single additional SYN packet and the corresponding RST from the fake MX. Running TCP dump on the fake primary MX and the real one indicated that there is almost no delay between the RST and the next SYN to the real MX. In our case we are using the Spamhaus Zen RBL -> Grey Listing -> checking valid recipients -> Spamassassin/ClamAV and last month blocked over 9 million messages, more than 98% of all inbound. Of that 98%, the RBL blocked about 98% of them. Adding nolisting simple means less DNS lookups with no other penalty that I have been able to determine. Agreed, it does NOT address the mail being sent directly to our secondary MX but there is still a lot of primary MX only SPAM so, IMHO, it is worth doing and does have a positive effect. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen and Rosanne Eustace GodZone Internet Services, a division of AGRE Enterprises Ltd. P.O. Box 8020, Palmerston North, New Zealand 4446. Ph: +64 6 357 8168, Fax +64 6 357 8165, Mob: +64 21 424 015 http://www.godzone.net.nz "A Ministry specialising in providing low-cost Internet Services to NZ Christian Churches, Ministries and Organisations."
-----Original Message----- From: Glen Eustace [mailto:geustace(a)godzone.net.nz] Sent: Tuesday, 15 January 2008 10:43 a.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Using nolisting to reduce spam
Yesterday, I came across the concept of 'nolisting' as a technique for reducing the volume of inbound spam. It wasn't something I had previously come across so have done some reading on the topic. http://nolisting.org as a starting point.
For such a simple technique, I was surprised by its impact.
Simply speaking, the idea is to use a primary MX that doesn't listen on port 25 but simply rejects the connection. Well behaved MTAs will all try the secondary MX(es) and delivery will occur. Many spambots only try the primary so there is an immediately benefit, less inbound to check in other ways and a consequential increase in the available resources on the mail server(s).
I set it up on one domain and behavior seems to be exactly as described. My reading suggests that there is no negative impact on legitimate mail and no noticeable additional latency in delivery as
the
switch from the primary to secondary on a reject is almost instantaneous.
I was wondering whether anyone else has had any experience with this technique and if so whether the claim that it has no negative impact is true. Also, if people haven't heard of it, it may be something people might want to look at as another weapon in the anti-spam war.
Glen.
_______________________________________________
Nolisting sounds like a bad idea, at least for many of the sites I manage. One big problem that springs to mind is "increased IP traffic" on not only public internet connections but private office ones too. Doesn't sound too bad until you get a few thousand hosts bouncing off a dead MX to discover the real(secondary) one. This is also true for bad hosts, who will be retrying to send their spam over our connection. From one MX to the other, the bandwidth all adds up. The other thing that worries me is that this all relies on a "well behaved MTA" for transporting all our clients email. Does that include Microsoft Exchange? We use multiple exchange servers, which in turn use our Qmail server. Do you think everything will play nice in this environment? (or are we going to expect a hefty log file full of connection errors). I reckon nolisting might be a good idea for small business, but not large business, which already ought to have state-of-the-art antispam/antivirus software installed with some kind of RBL technology. And, if it's anything like Spamassassin and ClamAV, should be working really well. Nolisting also sounds like it could be a very temporary thing before it is undermined by the demon-beast Spam, as their config has to change little to spam second or tertiary mx's first. Cheers Mike
For years we have run multiple MX records, and for years viruses in particular have targetted the secondary MX as an easier way into the enterprise, on the theory that the security defences on a backup route may be weaker. We have also noticed when our primary MX path is down, some mail servers - that should know better - don't swap to the secondary MX, and when the primary MX path comes up again, lo and behold fresh mail arrives. Spammers, never slow to pick up on any technique, are also likely to be aware of the nolisting technique, so I would say any relief is likely to be temporary. In short, I'd suggest using a good spam filtering tool with good reporting, so you are aware of what is going on. This is what we have used with great success: http://www.barracudanetworks.com Jeremy +64 21 990 177 Jeremy(a)Strachanconsulting.co.nz
Glen Eustace wrote:
Yesterday, I came across the concept of 'nolisting' as a technique for reducing the volume of inbound spam. It wasn't something I had previously come across so have done some reading on the topic. http://nolisting.org as a starting point.
I haven't heard of people using this for the primary MX, and I'm not sure that doing so classifies you as a good net citizen (despite the "it's only 2 packets" argument), however... Putting in a non-functioning low priority MX record is a trick that's been around for a while, and seems to have good results. As others have stated many spam programs go straight to the lowest priority MX record in order to (possibly) avoid anti-spam software, and most will not even try any other MXes, even if the lowest fails. The difference between this and using it as the highest priority MX is that the incidence of legitimate mail using the lowest priority MX is somewhere between low and very, very low (depending on your network, etc). As for the primary, how long until it hits the blogs/press/etc that company X's primary mail server has been down for the past 3 months! ("When contacted the company said 'yeah, we know - we like it that way!'") Scott.
Scott Howard wrote:
As for the primary, how long until it hits the blogs/press/etc that company X's primary mail server has been down for the past 3 months! ("When contacted the company said 'yeah, we know - we like it that way!'")
Thanks for this comment, something to consider. MTAs that are following protocols, from my observations, would appear to not even report the fact that the highest priority MX is unavailable and just deliver straight to the next MX in the chain. So, I am not sure what would lead to people being even aware of the fact unless someone specifically tests the connection as it wouldn't be effecting mail delivery to company X. Further to my posting to this list, I had a number of replies from people on the postfix list. None of them were negative and whilst a couple did point out that they have seen a swing towards Spammers targetting the lowest priority MX only, there is still a lot of spam/virus traffic against the primary MX only and that the technique is worth doing ( for them ). I have now implemented 'nolisting' on all the domains we host, as a trial, and will try to collect some empirical evidence as to whether it is in fact worth doing. It is pretty easy to turn off/on. Whilst I accept that it is not a technique that will even work, appeal or even be considered by some, I am still looking at defense in depth and every technique I can find I will consider. I will post the results in a few weeks time. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen and Rosanne Eustace GodZone Internet Services, a division of AGRE Enterprises Ltd. P.O. Box 8020, Palmerston North, New Zealand 4446. Ph: +64 6 357 8168, Fax +64 6 357 8165, Mob: +64 21 424 015 http://www.godzone.net.nz "A Ministry specialising in providing low-cost Internet Services to NZ Christian Churches, Ministries and Organisations."
participants (18)
-
Barry Murphy -
Brian E Carpenter -
Chris Curtis -
Damon Coursey -
Gerard Creamer -
Glen Eustace -
Greg Soffe -
Jeremy Strachan -
Mark Foster -
Mark Smith -
Martin Kealey -
Michael Hutchinson -
Nathan Ward -
Richard Hector -
Russell Fulton -
Scott Howard -
Tim Price -
TreeNet Admin