> There are extreme, pathological cases that greylisting bothers. eg, > legit servers that aren't RFC-compatible and simply NEVER retry > after seeing a 4xx reject, or servers that retry 12+ hours after a > 4xx reject.
Yep, but there are also MTA behaviors that are *not* so easy to demonize that also prevent efficient delivery when they encounter common greylisting implementations. One is the shuffling of outbound mail across servers in a mail delivery farm during the retry interval. As a result, the source IP of each attempt, and thus the triplet, is different. In such cases, you have to just cross your fingers that the original triplet comes around again before the client screams. Greylisting based on the Class C will help when applicable, but that's not available in all greylisting imps (IMO, greylisting should not be said to be implemented in a product *unless* it supports Class C tuples, with Class C the default setting, but this is not always the case). Another is the use of MXs that do not share the same greylisting database. I know you and I agree that all MXs should enforce the exact same policies. (You've also taken the stance that backup MXs should be administratively down until failure of the primary is detected, which is persuasive, but let's admit that in reality this is rarely done.) But even if the exact same policies are enforced in a standalone sense, it may not be practical to have a "shared state" across geographically dispersed and highly active MXs when it comes to greylisting. As a result, each MX is building an independent triplet database, and while that will have no substantive effect on the time for the *first* message to pass greylisting, it will take at least n = (number of unsync'd MXs of lowest weight) messages with the same triplet coming in before each MX database is up-to-date. MXs on the same LAN may have no excuse not to have some kind of synchronization, yes, but busy faraway and/or externally managed MXs, no. This problem fixes itself over time, but will that happen before you lose a client? Maybe, maybe not. A third is really human behavior, not MTA behavior. It's a basic imbalance between the size/entitlement/respect of the sending side of a business relationship and the receiving side. To say that the expectation of first-time delivery is a mistake to be corrected by the sender (when you ask why the senders aren't "retrying in less than 12 hours, in the first place") is wishful thinking. If I'm a small mutual fund provider and I want Charles Schwab to sell my funds, sorry, Schwab has every "right," such as it is, to be on a 2-, 3-, or 4-hour retry interval because of their status in the industry and huge volume. If my use of greylisting means their first response to my sales group gets delayed 4 hours, that's my fault, period. No one is ever going to blame them. Believe me, I've tried, even going on the record with claptrap like "Any 800-pound gorilla should ensure that their mail farm is sized correctly for a 15- or 30-minute retry interval," but the backlash was strong. I can't risk losing a client over that declaration, even if online support communities think it's right. The big wildcard with greylisting and any "give-to-get" anti-spam tactic are the business relationships to which we all owe our jobs. And critical groups like sales, who for better or worse define those business relationships that override technical "truth," rarely give IT a "preview" of their current campaigns to ensure prewhitelisting. It just doesn't work like that, even in very successful companies. Much as we all would like to think the quality of the interface with IT should be directly linked to a company's success -- it's not. > The chances of any specific MX actually seeing one of these > RFC-incompatible nutjobs is extremely small. The not-so-nutty exceptions are encountered by sites big and small: I have experienced all three in teeny-tiny sites. Maybe that's bad luck, but that's clearly the way it's been for David as well. The first behavior I mention above was just last week being experienced by one of my very small clients, one of whose only slightly bigger customers uses a giant French ISP for their business accounts. Do I think the customer is a "real" business? Hard to say. Joke, technically speaking. But I can't front on the business they bring in, nor can I disagree with the ISP's use of many MXs on multiple subnets. The ISP reasons that they're dealing with personal traffic, so they don't care that their architecture might be problematic for some business recipients. Their goal is a highly robust, multi-tier outbound queue. Nothing non-RFC about it. They do it, we deal with it. Now, bear in mind that I have been a proponent of greylisting from the get. I used it as soon as I could, but I also dealt with user outrage immediately. Since then, I have taken a more conservative approach. Conditional greylisting, where a g/l triplet is only considered if other tests, such as DNSBL or PTR lookup failures or other thresholds met, is infinitely safer, because you can point to more examples of misdeeds on the sender's end besides just "How dare they send to us for the first time?" :) --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
