> My mail servers are not there for Verizon to block their spam with, > nor anyone else that wants to use SAV.
Your argument is only consistent if you believe that domain-only validation (rather than user/LHS + domain/RHS) is *also* inappropriate, since aren't your _DNS_ servers *also* "not there for Verizon to block their spam with"? For that matter, what gives you the right to check to see if a connecting IP that forges the HELO of mail.example.com passes a HELO-A-PTR roundtrip? Doesn't that necessitate the unilateral use of example.com's DNS servers, which are "not there for" your internal spam measures? And the list goes on. > Yesterday we were connected to 898 times by Verizon to validate > addresses, and 697 of those connections were for addresses that don't > exist. To make matters worse, when they get a 550 for a bad address > using a null sender, they RSET and try again using a named Mail From, so > they actually tried bad addresses 1,394 times in just one day. Who has > a right to pound a server with 1,394 bad addresses a day? Pound with 1,394 RCPTs? You should be able to handle millions of RCPT lookups per day, or even per hour, without blinking! When you can handle the traffic and are just trying to keep your addresses out of spammers' hands, it can be frustrating to try to use simple anti-dictionary attack logic in a complex world; I can appreciate that. But this whole pity-me logic for a couple thousand lookups is kind of weird. > The RFC suggests that 3 minutes [to respond to SMTP commands] is > reasonable, and to go all the way down to 30 seconds is really > pushing it in a world where there is both tarpitting and many > servers with performance issues due to spam. If you can't respond to RCPT TO validation in less than 30 seconds, that sucks for you, but it's not representative. OTOH, if you just *won't* respond to RCPT TO validation in that time, I doubt you're really benefiting from purposely tying up a socket for 3 minutes; tarpitting usually ends up shooting servers in the foot unless tarpitting, like everything else, adjusts intelligently to true threats. Anyway, the less forged-sender spam gets accepted, the fewer performance demands there are for that spam. The aggregate CPU utilization of an SAV-based rejection, including the inbound HELO/MAIL FROM/RCPT TO and the subsequent callout, is far less than what would be used for content scanning. That's why SAV is done. Yes, the bulk of the resource savings is on the receiving side of any transaction; the direct achievement of SAV is protecting the receiver's MX and mailboxes from abuse, without any inherent regard for the physical resources of the sender domain. But the indirect result is to force visibility -- either through blatantly fraudulent JJ of extant [EMAIL PROTECTED], or through the use of spammer-only domains -- rather than letting spammers hide behind unattended/nonexistent addresses. Again, I'm not saying SAV is without problems, but you're throwing some FUD on the fire here... considering that just yesterday you were characterizing Verizon's actions as something completely different and totally without precedent. --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/
