On Mon, 2006-02-13 at 19:43 -0500, Joe Polk wrote:

...

It sounds like it will do the trick, then. Should we use it and SA or ditch SA? It sounds like some are.

I would keep spamassassin. Greylisting gets most of the spam but some spam comes from legit MTAs. Spamassassin will catch most of the remaining spam messages. Greylisting alone will get about 98 to 99% of the spam. Spamassassin will catch almost all the rest. This is based om my experience with such a setup.

On Tue, 2006-02-14 at 11:15 -0800, Benjamin Smith wrote:

On Monday 13 February 2006 16:43, Joe Polk wrote:

...

It sounds like it will do the trick, then. Should we use it and SA or ditch SA? It sounds like some are.

The biggest problem I have with SA is that it gets it wrong often enough to be basically worthless. I mean, great - you filter on subject line, looking for "{Spam?}", but then you still have to go thru the junk folder in order to look for false positives, and then you end up reading through all the "P3n1s P|LLS" emails.

Gee, didn't we want to avoid this?

The trick with using spamassassin is adjusting the rule sets and getting bayes trained on your particular type of email. Once trained I have not had any false positives and only a few spam get through each week. This is on a system that only uses spamassassin (sadly I don't control the MTA that this system gets email from so greylisting is not an option).

http://www.rulesemporium.com/ has a number of excellent rules sets that improve detection rates and reduce or eliminate false positives.

Greylisting + blacklists equals good performance, no false positives, and greatly reduced spam volume, and usually reduced server loads as well. The blacklists I use are xbl-sbl.spamhaus.org, and the dialup/dsl list, as well as a few worst-offender countries. (EG: China, Korea, and Russia)

That is another very good solution.

Am Di, den 14.02.2006 schrieb Johnny Hughes um 20:38:

...

The biggest problem I have with SA is that it gets it wrong often enough to be basically worthless. I mean, great - you filter on subject line, looking for "{Spam?}", but then you still have to go thru the junk folder in order to look for false positives, and then you end up reading through all the "P3n1s P|LLS" emails.

Gee, didn't we want to avoid this?

That isn't true ... I don't mark the SPAM, i send it to a separate folder that the users never see. I delete files older than 2 weeks from the folder. If someone complains that an e-mail didn't get to them (happens maybe once in a 3 month period) and it's less than 2 weeks old, I find it and give it to them.

Here in Germany this kind of setup violates law heavily - called mail suppression. If you don't like the idea to see a prison from inside you better not do so in Germany when being a mail provider (or university or so).

Alexander

Quoting Benjamin Smith lists@benjamindsmith.com:

Greylisting + blacklists equals good performance, no false positives

Greylisting can have false positivies, or can introduce very long delays. It can also have nasty side effects, esp. if other side has brain dead MTA. So, before deploying greylisting and talking about it as "best invention since sliced bread", couple of things to think about.

Some sites have farms of outgoing mail servers, so IP address will be different on almost every re-delivery attempt. If greylisting is matching IP address, sender, recipient triplet, obviosly such email isn't going to be accepted (it will keep getting temporary failures). This is usually solved by whitelisting domains that has such server farms. Milter-greylist comes with such a list in default configuration file. However, at one ocasion this resulted in one very important email for my wife being delayed for several days (the site was not known to milter-greylist as having outgoing mail server farm). I ended up disabling IP address check after some time (just checking sender-recipient pair). The effectivnes reduced slightly, but still more than acceptable.

Email sent to multiple recipients. Depending on implementation of greylisting used (don't remember how milter-greylist implements it), if sender has passed greylisting only with some recipients, you'll get people complaining that guy in cubicle next to his got this ultra high important email, but they haven't. Of course, they will. A bit later. But still, look at it from users perspective. They don't know anything about greylisting and expect email to be like instant messaging (which it is not, but they don't know that).

Delays... you can expect delays as long as one hour when email for particular sender/recipient pair is seen by greylisting for the very first time. Sometimes even longer (on very rare ocasions). In some environments this might not be acceptable. When outside user sends email to support email address with some data (while still on the phone), he expects support person will get it in matter of seconds. Not hours.

Some sites have several outgoing mail queues that implement backing off strategy (to make running queue runs on large queues managable). They'll try several delivery attempts during first couple of hours, then move email to slower queue that tries maybe couple per day, then move to even slower queue that runs maybe only once per day. Depending on timeout values configured for greylisting in combinataion with your (or their) server/network downtimes, this may make some mail not to be delivered. I haven't seen this happen in real life, but there's theoretical possibility.

Broken MTA software... Some real-life examples I encountered.

I had one client whose MTA would treat temporary failures like permanent failures, no re-delivery attempts, bounce emails as undeliverable to sender right away. Don't remember what they were using. Solved that by whitelisting them. But you never know when you are going to run to somebody else using same broken product.

Symantec antivirus for email gateways or something like that (not sure if all versions of the product). There's some other products that do this by default. It sends warning message back to sender on first temporary failure. Users, the way they are, not reading what the message says, either try to resend right away (and get another bounce, since greylisting period wasn't yet reached), or start complaining that their emails haven't made through. It's questinably broken MTA, since there's nothing in the standards preventing MTA from doing so. Non-technical people might even like the "feauture", being warned if email is not delivered right-away -- the only thing it's unreliable and can get you into making wrong conclusions (that email was delivered, when it is still somewhere in transit).

And finally, seems some spammers are falling back to good old exploiting of open relays. I'm seeing slight but constant increase of those. While greylisting works wonders when other side uses mass-mailing software, it is useless against real MTA.

In short, greylisting is "the best invention since sliced bread". However it has some gotchas that those using it should be aware of. And it's not 100% false positives free. More like around 99.99999%. Enjoy using it while it is still effective.

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.