|
Donation/Premium |
|
 |
|
|
|
|
|
|
|
Survey |
|
|
|
|
|
|
|
|
|
|
|
| View previous topic :: View next topic |
| Author |
Message |
stan_qaz
Premium Member
Joined: Mar 31, 2003
Posts: 10629
|
 Posted: Tue Dec 19, 2006 6:07 pm Post subject: |
|
|
Any time limit you added to your greylisting setup would have to allow legitimate new addresses through at some point or legit servers couldn't deliver any mail from new addresses to your server.
Once you allow new mail addresses from a legit server based on a sequence of retries all the spammers have to do is set their spam generators to the same time sequence and they are in.
The only reason greylisting works now is that it isn't enough of a problem that a spammer has taken the time off spamming and spending their ill gotten gains to code a anti-greylisting option into their spam generators.
I wonder if a spammer will code something up before some legitimate mail admin builds a tool to detect folks greylisting his server and blocks sending to their domains as a waste of his/her processing time?
_________________
Questions? Try the wiki
http://wiki.castlecops.com/MailWasher_Pro
|
|
| Back to top |
|
 |
Ikeb
Special Response Team
Forums Admin
Joined: Apr 20, 2003
Posts: 16515
|
| Posted: Wed Dec 20, 2006 2:10 pm Post subject: |
|
|
Of course. For some reason I thought that the tempfail must include a "retry after x hours" mechanism. That's the only way it couldn't be easily defeated.
|
|
| Back to top |
|
|
stan_qaz
Premium Member
Joined: Mar 31, 2003
Posts: 10629
|
| Posted: Wed Dec 20, 2006 10:24 pm Post subject: |
|
|
More on the greylisting concept, this is long but an excellent read, it raises a couple points I hadn't considered too.
http://projects.puremagic.com/greylisting/whitepaper.html
On delay time:
| Quote: | The initial delay of 1 hour was picked for several reasons:
1. An hour is short enough that in most cases, users will not notice the delay.
2. It is long enough to give time for administrators on a possibly compromised or abused mail server to discover the problem and hopefully correct it, before any of the offending email is able to be delivered.
3. It is long enough to provide a good chance that if the sending host is in fact a spammer, they will be listed in other IP-based blacklists that may be used in conjunction with Greylisting, so that even if a spamming relay later attempts a redelivery that would no longer be delayed by Greylisting, it may still be blocked by other methods.
4. It is also long enough that other types of traffic analysis could be designed and implemented such that spamming IP's could be easily identified and blocked by other methods, in such a way that even the first recipients (before a spamming pattern starts to emerge) would still not be bothered by the spam email.
The data collected during testing showed that more than 99% of the mail that was blocked with the tested setting of 1 hour would still have been blocked with a delay setting of only 1 minute. However, it is expected that as spammers become aware of this blocking method, they will change their software to retry failed deliveries. At that point, having a larger initial delay will definitely help, as it gives time for other blocking methods to act. For this reason, it is suggested that at least a one hour delay value be kept as a default, since spammers will start adapting as soon as this method becomes known and starts being used.
It is important to keep this delay smaller than a value where a significant number of MTA's will give up and bounce the message. Luckily, most MTA's have failure timeouts of several days. However, there are some special cases like certain financial institutions who want to know that it wasn't delivered in a fairly short period of time. Even in these special cases, the timeouts should be at least a few hours. |
The effectiveness of greylisting in combination with other blacklist services running on a mail server is something I had not considered. It is something worth considering IF you have a weighted anti-spam system that considers many aspects of the message, not just the blacklisting of the sending mail server - which can generate too many false positives for my taste.
| Quote: | Possible methods of spammer adaptation
Greylisting as proposed is fairly immune to possible routes of adaptation by spammers to get around the blocking. The possible methods of adaptation may make Greylisting by itself less effective, but the ways of getting around it will only make other spamblocking methods more effective.
The normal spammer behavior is to change IP's when normal IP blacklists have listed their current IP. Unfortunately for the spammers, changing their IP does not help with our delaying method, as every mail (and its delay) is tied to the IP address of the sending relay. If the IP address changes, it effectively "resets" the timer on the delay, even if the envelope sender and recipient addresses stay exactly the same.
The other adaptation that is expected will result in the current versions of client spam software becoming obsolete, since most of those spamming applications are not intelligent enough to retry a delivery after getting any type of error. Spammers will be required to either use more intelligent software that retries, or to relay through smart relays.
We may see spammers gravitate toward using open third party relays, but most of them are already locked down or are quickly becoming so. Or, they may setup their own relays. In either case, it does nothing to negate the likelihood that those relays are or will quickly become listed in blacklists, thereby reducing their effectiveness for sending spam.
If spammers setup their own relays, the fact that email transmissions are delayed and that they may each take several attempts to deliver, only increases the storage and bandwidth requirements on the spammers side, which also raises the costs to the spammer. And if we can make it less profitable, then we are well on the way to solving the spam problem. |
All told aside from a few unique cases greylisting may actually do rather well at blocking spam if run on the server today and if integrated with other tools could do well in the future..
_________________
Questions? Try the wiki
http://wiki.castlecops.com/MailWasher_Pro
|
|
| Back to top |
|
|
Ikeb
Special Response Team
Forums Admin
Joined: Apr 20, 2003
Posts: 16515
|
|
| Back to top |
|
|
stan_qaz
Premium Member
Joined: Mar 31, 2003
Posts: 10629
|
| Posted: Thu Dec 21, 2006 6:33 am Post subject: |
|
|
Personally I don't use DNSBLs alone for spam blocking. I do use spamcop to identify spam already listed there so I don't report stuff already listed.
One of my mail providers uses Declude that uses several DNSBLs in their weighting. These were on one that was in my inbox as I was typing this.
cbl.abuseat.org
spamcop.net
www.mxrate.com
www.sorbs.net
blackholes.five-ten-sg.com
blacklist.spambag.org
I'm too lazy to take a look at the Declude list and see how many relay blocking lists are still active but I'd assume several still are. This is from a recent spamcop.net report:
12.217.102.72 not listed in dnsbl.njabl.org
12.217.102.72 not listed in dnsbl.njabl.org
12.217.102.72 not listed in cbl.abuseat.org
12.217.102.72 listed in dnsbl.sorbs.net ( 127.0.0.10 )
12.217.102.72 not listed in relays.ordb.org.
12.217.102.72 not listed in accredit.habeas.com
12.217.102.72 not listed in plus.bondedsender.org
12.217.102.72 not listed in iadb.isipp.com
Maybe someone should mention the ORDB shutdown to them 
_________________
Questions? Try the wiki
http://wiki.castlecops.com/MailWasher_Pro
|
|
| Back to top |
|
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
Powered by phpBB © 2001 phpBB Group
|
Forum FAQ
Search
Usergroups
Profile
Login to check your private messages
Login
