On Fri, 10 Dec 2004, Rich Kulawiec wrote:
Verizon has put in place an exceedingly stupid "anti-spam" system which does not work, which facilitates DoS attacks, and which provides active assistance to spammers.
The technique discussed is called callback verification and I do not agree that the technique stupid or provides assistance to spammers. I do agree that some of the aspects in how this was implemented by Verizon is not correct and causing problems.
Details:
When an incoming SMTP connection is made to one of Verizon's MX's, they allow it to proceed until the putative sender is specified, i.e. they wait for this part of the SMTP transaction:
MAIL From:<blah@example.com>
Then they pause the incoming connection. And then they start up an outbound SMTP connection from somewhere else on Verizon's network, back to one of the MX's for example.com. They then attempt to verify that "blah" is a valid, deliverable address there. Since most people have long since disabled SMTP VRFY, they actually construct a fake message and attempt delivery with RCPT. If delivery looks like it's going to succeed, they hang up this connection (which is rude)
If I were them I'd do RSET first and then QUIT instead of direct hangup
, and un-pause the incoming one, and allow it to proceed. If delivery looks like it's going to fail, then they also hang up their outbound connection (still rude), un-pause the incoming one, and reject the traffic.
Rejection of traffic is not approriate in this case, the greylisting technique should instead be used and they should reply back with 4xx error code (most likely 421 or 451), this allows for retry of email later on instead of outright denial.
This also means that if the MX they try to connect to is (a) busy (b) down (c) unaware of all the deliverable addresses (d) something else, that they'll refuse the incoming message.
All good reasons explaining why error code should 4xx instead of 5xx as I noted above.
It also means that if the address that's trying to send mail to Verizon is something like "support@thuleracks.com", which is the address that the people at Thule Racks emit support traffic from, but which doesn't accept traffic, that Verizon will deny the message. (Yeah, this isn't very bright on Thule's part, either.)
They are correct in this case. The address entered in RFC2821 MAIL FROM is "Bounces-To" address and it must accept bounced email and as such it must accept incoming emails. If the address does not accept traffic as you indicated should not be used in MAIL FROM and different adddress from local machine should be used. Please read email RFCs and then you'll understand that Envelope MAIL FROM (despite its name) is not an address that indicate source of email, the source of email address is actually "From:" header (or in some cases Sender header - which one to use will depend on your situation)
This is bad for a whole bunch of reasons: two of the more obvious ones are (a) it's a pathetic "anti-spam" measure because ANY forged address ANYWHERE will do I agree that it requires verification that connecting machine has right to use given mail-from address as part of its sending email. See SPF.
But for current situation it does work just fine and causes number of emails with randomly generated emails to be stopped.
, and (b) it doesn't scale.
The scalability depends on implementation. Since we have Verizon implementing it, I'm guessing it scales just fine based on the size of their email network. I'll also note that a lot of email is sent from the same address and as long as they cache results of verification it'll not be necessary to do verification each and every time.
Add to that (c) it abuses RCPT because apparently Verizon is unwilling to use VRFY and to accept the decision of many mail server operators to disable it. Oh, and (d) the behavior of their probe systems is nearly indistinguishable from that of spam-spewing zombies, which don't obey the SMTP protocol either.
Sometimes spammers probe various address before sending email to compile new list of email addresses and they use similar technique, however those are in fact distinguishable because you'll see them probing multiple non-existing address usually in alphabetical order. If email is sent from real working addresses, the callback verification would not look like a spammer probing technique.
[ (b) is also how it lends itself to DoS attacks. Sure, Verizon could rate-limit the rate at which they make outbound connections, but then attacker X could impose significant delay on mail from domain Y just by forging a boatload of messages purporting to be from addresses in Y to Verizon. If Verizon rate-limits their outbound connections, then any real messages from Y will be stuck in the verification queue along with a kazillion forgeries.
As with many techniques trying to address problems of current email infrastructure with temporary solutions, it has weaknesses that made those using vulnerable to specialized DoS attacks. This is nothing new and that is why IETF requires "Security Considerations" section for every draft. Obviously addressing possible security weaknesses is a task for implementor of the technique and as you point out Verizon could use rate-limiting to protect against ongoing attack. I'll also note that rate-limiting is used to protect many kind of attacks (including ip and web DoS) and in all cases it causes some legitimate requests to be delayed along with large number of attacks sources. This is considered to be acceptable temporary situation in order to protect against larger problem.
General principle: any "anti-spam" measure that generates more junk SMTP traffic at a time when we're drowning in it is probably a bad idea. ]
Callback verification if properly implemented will never generate more junk SMTP traffic as DATA part of SMTP transmission never happens. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam and Email Security Research Worksite: http://www.elan.net/~william/emailsecurity/