You should better except first-contact email adresses as "sales" or "info" from greylisting.
Good greylisting implementations support lists for server Adresses to be excluded - so you can exclude the major world wide email services -which did not send from a single netblock- from greylisting too. Even a 0 minute Greylisting (allow second attempt directly after the first 4xx) stops lots of spam. ASSP supports all these exclusions and is already deliverd with a exemption list. Even with lots of exclusions, greylisting does a great job to stop Zombie-Mailers and viruses. I think any responsibly configured email server will retry a 4xx error after a short period - greylisting is widely spreaded and commonly used. Matti >> 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/ - Matti Haack - Hit Haack IT Service Gmbh Poltlbauer Weg 4, D-94036 Passau +49 851 50477-22 Fax: +49 851 50477-29 http://www.haack-it.de Besuchen Sie jetzt unseren neuen INTERNET&NETWORK Security Shop mit faszinierenden Angeboten rund um Ihre Netzwerk- Sicherheit: http://www.inn.de -- Ausgehende E-Mail wurde auf Viren gescannt -- 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/
