Any plans on adding this functionality to the C-Series? It's still surprisingly effective after all these years and could potentially increase capacity of the device.
Effective implementations I've worked with had two greylisting features in common:
-the 4xx tempfail was done *after* the SMTP DATA command (not after RCPT TO:) This works around the buggy SMTP implementations of a couple well known and widely deployed commercial mail server products that shall go unnamed ;)
-Valid senders (those that passed greylisting) where cached for a lengthy period (>= 30 days) This minimizes delivery delays and end user complaints. Ideally this would be a tunable parameter.
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.
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.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :