Do you use greylisting?
Submitted by root on Sun 2 Sep 2007
| Huh? |
![]() 42% | 472 votes |
| No |
![]() 31% | 352 votes |
| Yes |
![]() 25% | 284 votes |
| Total 1109 votes |
I would, but our central IT does greylisting upstream, so there'd be little point in us slowing things down...
Cheers:wq
[ Parent ]
I considered to use it, but I'm not sure how much it realy performs. The world of spam changes realy fast. In our company we have greylisting and a lot of spam, too.
What do you think? Is it useful? Is there any percentage of restrained spam mails?
Remo
A programmer is just a tool which converts coca cola into code.
[ Parent ]
[ Parent ]
I like the spamtrap option that policyd has, would be useful to block AOL when the dictionary attacks begin (20-30 tries to unexistent accounts).
A year ago one user told me that from 7 spams a day he went to 1 or 2 a week.
[ Parent ]
| Date | Delivered without Delay | Greylisted | Greylisted, but Re-sent |
|---|---|---|---|
| 2007/09/11 | 222 | 136 | 30 |
| 2007/09/12 | 859 | 336 | 7 |
| 2007/09/13 | 888 | 270 | 9 |
| 2007/09/14 | 845 | 363 | 13 |
So we greylisted anywhere from 30-60% of our incoming email on those days. Aside from the first day, less than 3% of it ever got resent. Grepping through those logs, it looked like it was all spam to mailman administrative accounts, to moderated lists, or to my personal account. Everything else was delayed by an hour or less, and about 30% of it was delayed by 15 minutes or less. I'm sold.
[ Parent ]
[ Parent ]
i only have a handful of users and i found that greylisting reduced the amount of spam i received by almost half
i still need spamassassin and such running to get the rest, but this takes care of a lot of the ...lightweight... spam out there
the negative is that it can delay new email, but i find that a small price to pay when i can look at my inbox for several days in a row without one piece of spam having gotten through
and remember, if you delay spam, then you have more of a chance that DCC might have identified that message as spam and increase the chances that when it is redelivered (if it is redelivered) you'll id it as spam
aaron
[ Parent ]
most users know about our greylisting and they tell us the senders information in cases of emergency for whitelisting.
greylisting itself cuts down the spam to more than the half. its our second step,first we use dns-blocklists and 3rd spamassassin. so our spam situation is quite good and we have close to none false-positives.
problems seen with greylisting:
1. speed, but solved via whitelisting as written above.
2. misconfigured mailservers, retrying to fast/often using non-rfc intervals.
3. misconfigured mailservers, with unallowed chars in the hostnames, wich is not only a greylisting problem...
4. users of small companies often send directly, using dial-up addresses that change often and are filtred via dns-blocklists...althought they could use their providers mailserver, what could reduce whitelisting issues...
[ Parent ]
aaron
[ Parent ]
Guess a "I wouldn't start from there" kind of response.
[ Parent ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
When it comes to greylisting I've fallen back to the simpler "sender + recipient" pairs; that takes care of server-farms which have different IP blocks to send mail from.
I found prior to making that switch I had extremely delayed mail from senders such as googlemail - they'll first try sending from one IP, then later another, and later still a completely different one!
[ Parent ]
aaron
[ Parent ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
I guess it depends on what you're using, for me using qpsmtpd on Debian I just add this to qpsmtpd/plugins:
greylisting black_timeout 60 recipient 1 sender 1 remote_ip 0
The ones mean "include this data" when making the test, the zero means "don't include it". So here I include both sender address, recipient address, but not the IP.
[ Parent ]
This handles most of these cases fine, it also ships with a whitelist.
I've only come across very few exceptions, mostly very broken mail servers, or people with issues on the Postgrey mailing list. I remember part of IBM managed to ship email internally, via Lotus Notes, and defeat greylisting.
But also depends how busy your email server is, Postgrey whitelists at 5 successful deliveries (by default), so most of Google's mail servers were white-listed in a few days.
I would think sender/recipient pairs lead to a lot of spam passing greylisting, spam tending to have unimaginative data.
[ Parent ]
It requires action from the users, who most of the times don't understand the warn message or don't even want to read it, considering it's spam!
Additionnaly I guess it can slows a little mail delivery...
I realy don't like this kind of policy but I have to said it's an efficient way to get rid of almost all spam (I maybe of ham to!).
[ Parent ]
Any properly configured mail server shouldn't have any trouble with greylisting behavior, so you shouldn't have any lost ham.
Also, it shouldn't require any action from the users, and you shouldn't have any users getting warning messages about the fact that their mail's delayed, unless of course your mail server is blocking messages for far too long -- a few minutes is usually enough, rather than the hours that would be necessary to illicit a warning to the original sender.
Cheers.:wq
[ Parent ]
This way I can reject spam safe and accurately, and accept mail from most broken/weird servers (unless they have messed up retry times or something, but I'm yet to find such server).
I also mark mail originating from countries with high levels of spammers as suspect without risking losing legitimate mail, which leads to even less spams getting through.
[ Parent ]
In greylisting I use rather short delay only 1 minute.
On average day we have 20--40 thousands attempts delayed of which 5--10 percent tries it later. So greylisting seems to be still very efficient.
Several users complained, namely because of mixing delivery times of mails from mailing lists (when after long silence a thread starts, the first mail is delayed). So I put those users on whitelist.
Also I had to whitelist several IPs of some broken MTAs.
JDe
[ Parent ]
[ Parent ]
Read more about it here:
http://www.openbsd.org/cgi-bin/man.cgi?query=spamd
[ Parent ]

42%