North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: verizon.net and other email grief

  • From: william(at)elan.net
  • Date: Fri Dec 10 15:09:56 2004

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:<[email protected]>
>
> 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 "[email protected]", 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: [email protected]
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/