We I wouldn't call it like this, but this is just a technologies that will not work for large ISPs or enterprises.

If you think of a IronPort X1050 that juggels 4k Message per minutes having those to hold in the queue for 5 minutes more makes 20k message, just because some systems do this greylisting.

Even more: if greylisting is used a lot - overcoming its effect is 2 lines of bot code.

It works but is not a really good solution. You will slow down mail traffic a lot if you have more then a couple of hops.

In short - I also don't think we will implement it.

Cheers,

Mark

I just wanted to add that we're another site that had previously used greylisting quite sucessfully in the past (before we installed our C350s), and it's one feature that some people here would have liked us to continue to use. I realize that the reputation filtering is doing much the same thing, but if nothing else, it would be nice to be able to tell people "oh, and we're greylisting, too."

I'm not sure if you would classify us as an enterprise or not (about 4000 users and 250k inbound messages (including spam) a day), but we never saw a huge performance hit due to greylisting.

And even if most sites wouldn't use it, it would be a nice extra feature to just have available to those sites that would want it - and make Ironport more competitive against alternate solutions by offering more choices.

I do I agree on that bit. (except for the perf.)

I had a feature request done for this a while ago, where it was bundled into sendergroups to only do it for IP that also have a bad score.

It has not went through yet.

Cheers,

Mark

Greylisting is one of those technologies that is going to start failing badly one day soon.

Greylisting works entirely on the fact that spammers don't bother re-trying. It's not that spammers can't retry after a temporary failure error (ie, 4xx response code), it just that they don't bother as there's such a small benefit from doing do.

As more and more people use greylisting, eventually the spammers (or more specifically, the spamming bot writers) are going to decide that there's a worthwhile benefit in retrying connections in order to get around greylisting - and the moment they start doing that then greylisting is going to go from a worthwhile technology to completely pointless!

The IronPort combination of SenderBase Reputation and the ability to throttle connections based on reputation should achieve a better catch rate than greylisting will ever give you - and there's no way for spammers to get around it by just retrying!

Response to retrying and performance (from the POV of an enterprise doing mostly receiving)...

Perhaps most important: yes, already spam/malware has started retrying. Soon, nearly all will (maybe!). This doesn't matter. One of the nice benefits of greylisting is that it gives automated blocklists (RBLs and I'd assume senderbase) time to catchup via the honeypots. So, greylisting need not delay receipt for long, five to maybe ten minutes at most. That could be a lot of queuing at the sender, leading into the second point.

People have talked about Performance. From prior experience with a sendmail/spamassassin/mimedefange box implementing greylisting doesn't seem like it takes much resources compared to say the content scanning. There's little CPU or RAM load. Disk I/O is likely going to drop a bit since there will be less messages getting written to disk. What about the impact to the sender?

Indeed, it looks to me like comments here are talking performance from the standpoint of a *sender* who is being greylisted. Yes, greylisting increases the "price" of sending mail. From this receiver's point of view this is *NOT* a bad thing. Exactly why should I care about the foo marketing list outgoing queue? Furthermore, based on what we paid for our bottom-of-the-line Ironport I really don't want to hear people talk about cost because obviously this wasn't much of an issue! (hey you do get what you pay for; IPort works great!) NOTE: In practice, this price increase to the sender stemming from increased queuing due to greylisting induced delay should not be large. Read on....

Note in my original post about the requirements of a PROPER greylisting implementation. Namely, the requirement that the receiver doing the greylisting MUST (RFC2119 definition) cache (and NOT greylist) hosts that have successfully passed greylisting for a relatively long time (e.g. at least 30 days). Most large legitimate senders (i.e. hotmail, constantcontact.com, whatcounts, gmail, etc...) will have sent a mail every day to us. Certainly, I would say most orgs would get at least one mail a week from these large senders. I would think most receivers would have a fairly static list of domains they receive mail from on a regular basis; sorry I don't have any stats on that. Since we have smart greylisting, these domain/IP pairs will be in cache and SHOULD be updated every time they send (assuming same sending domain from same host). So, they are greylisted once. If a sender is not sending much mail then my opinion is the queuing is their cost of doing business and shouldn't be a problem anyway since they are at a low volume. High volume legit sender? When you are charging thousands of bucks a year for hosting relatively small marketing lists (ahem whatcounts) then please, buy a bigger SAN for your queue.

Yes there are many broken greylisting implementations out there that greylist every mail from every host every time. Please do not base your opinions on these broken implementations.

Hopefully this feature request will merit further review. Thanks for reading.