Subject: [Asrg] Verizon's asymmetrical anti-spam causing problems

From: "Peter Kay" <[email-masked]>
Date: Mon, 7 Mar 2005 20:55:42 -1000

Has anyone noticed/experienced Verizon's asymmetrical anti-spam email
address verification?  After you connect to their mail servers and send the
MAIL-FROM / RCPT-TO commands, before they come back with an OK, they do a
reverse check of the MAIL-FROM address to see if it's valid and if not,
return a fatal error.
 
While Verizon is certainly not the only ISP doing address verification, and
I'm personally in favor of the approach, what I object to is that their
approach is not symmetrical, meaning that if another server (e.g.
Mailsender.com) were to employ the identical method that Verizon does,
neither Verizon nor Mailsender.com would be able to send each other email.
 
The reason for this asymmetry is that the Verizon probe addresses are in the
form of  <mailto:[email-masked]>
[email-masked] or something to that effect where xxxx is a 4
digit number. So if Mailsender.com used probes like
<mailto:[email-masked]> [email-masked]
you can see the problem, that being:
 
A. Mailsender sends email to Verizon.
B. Verizon holds the connection and attempts a probe to Mailsender.
C. Mailsender holds the connection and attempts a probe to Verizon.
D. (does this create an infinite loop?)
E. Verizon's probe fails.
F. Mailsender's probe fails.
G. Legitimate email is never sent. 
 
Has anyone else had problems with this? I did quick check on their site and
didn't find anything.
 
Have there been any BCP or equivalent on email address verification? I
haven't easily found any.
 
Peter Kay
Titan Key Software
Unique spam-bouncing technology
 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Josh Rollyson <[email-masked]>
Date: Tue, 08 Mar 2005 03:15:42 -0500

Peter Kay wrote:
> address verification?  After you connect to their mail servers and send 
> the MAIL-FROM / RCPT-TO commands, before they come back with an OK, they 
> do a reverse check of the MAIL-FROM address to see if it's valid and if 
> not, return a fatal error.
>  
> While Verizon is certainly not the only ISP doing address verification, 
> and I'm personally in favor of the approach, what I object to is that 
> their approach is not symmetrical, meaning that if another server (e.g. 
> The reason for this asymmetry is that the Verizon probe addresses are in 
> the form of [email-masked] 
> <mailto:[email-masked]> or something to that effect where 
> xxxx is a 4 digit number. So if Mailsender.com used probes like 
> [email-masked] 
> <mailto:[email-masked]> you can see the problem, that 
> being:
>  
> Has anyone else had problems with this? I did quick check on their site 
> and didn't find anything.
>  

The SAFEST return address for probes of that type would be a null sender 
<>, simply by virtue of it not generating a reply. However, some very 
misguided postmasters block support for null senders, which also 
effectively blocks bounce messages, without having any real impact on 
blocking spam.

Timeouts with fail-open design can help with the above scenario though, 
at the risk of letting some spam through.

I've not seen any BCP on this either, theroretically VRFY is designed 
for the purpose, but nobody in their right mind permits it these days 
because its just as useful for spammers to check their lists.

Maybe an extended VRFY replacement that takes a messageid and an email 
address, and verifies that the server handled a message from that 
sender, with that messageid recently? Of course, this would take years 
to implement, and might not ever get widespread support. (And still has 
its own problems)

---

From: Jose Marcio Martins da Cruz <[email-masked]>
Date: Tue, 08 Mar 2005 10:41:24 +0100

Peter Kay wrote:
...
> and didn't find anything.

Yes. How to identify if the server is verifying existence of senders of
harvesting email addresses ? Some sites (the mine one, e.g.) blacklists
sites doing too much recipient address errors.

> Unique spam-bouncing technology

Jose-Marcio

---

From: "Steven G. Willis" <[email-masked]>
Date: Tue, 8 Mar 2005 12:26:01 +0000

>effectively blocks bounce messages, without having any real impact on 

Mr. Rollyson,

Do you have any data to justify such a claim regarding filtering of email using
an empty MAIL FROM 2821 header as a parameter in an automated decision making
process?

I would be very curious to see any data that you have on this subject to support
your claim. I am sure the ASRG group would find such data to be extremely
useful.

Cheers!

================================================================
Steven G. Willis     [email-masked]       866.224.3058
Deep Sky Technologies, Inc.          http://www.deepskytech.com/
http://www.badchickens.com/         http://www.store-secure.com/
AIM-iChat: dstisgwillis
================================================================
        Why is "phonics" not spelled the way it sounds?
================================================================

---

From: "Dennis Dayman" <[email-masked]>
Date: Tue, 8 Mar 2005 06:45:37 -0600

> The SAFEST return address for probes of that type would be a 
> null sender <>, simply by virtue of it not generating a 
> reply. However, some very misguided postmasters block support 
> for null senders, which also effectively blocks bounce 
> messages, without having any real impact on blocking spam.

They are using a null from first, ie. <>, and if they receive a 500-series
error after the 'mail from:' command or after the 'rcpt to:' command, they
issue a 'rset' (reset) and issue 'mail from:
[email-masked]', the asterisks representing a string of six
random numbers.  They setup a wildcard account for west.verizon.net on the
mail system in case the remote host performs Sender Verifications checks.

-Dennis "Used to work for Verizon abuse" Dayman

---

From: "Richard Johnson" <[email-masked]>
Date: Tue, 8 Mar 2005 14:33:27 -0700

At 20:55 -1000 on 2005/03/07, Peter Kay wrote:
> Has anyone else had problems with [verizon's attempts at sender address
> verification]? I did quick check on their site and didn't find anything.

Heh, you should not expect Verizon, a provider that in the aggregate sends
much spam due to their poor control of their own network, to trumpet the
brokenness of their own anti-spam measures.

That brokenness is inherent, and is exacerbated by Verizon's attempts being
assymetric in IP space as well as in email address space.  Their assymetry
neatly dodges reciprocal whitelists, in both IP space and email address
space.

Given the spam DoS load that Verizon's networks present to our servers, we
necessarily have Verizon's domain and networks blocklisted, except for
specific addresses our users have individually whitelisted.  Given
Verizon's demonstrated lack of control of their own network, that is a
reasonable and prudent anti-spam measure.

Furthermore, when one of our users sends mail to Verizon, we can set up
additional reciprocal whitelists to allow replies from both the destination
network and the destination email address.  Sadly for Verizon, their
misguided attempt at sender address verification dodges both.

Rather than attempting their "verification" from the same network as the
destination MX, they connect from an entirely different network, thus
missing the whitelisting.

Worse, rather than using the original recipient's email address as the MAIL
FROM in their verification attempt, they pick something nonsensical and
spammer-like, missing that whitelisting as well.

Add in their attempts to "verify" forged sender addresses, and they have an
even bigger problem.  They're constantly making unsolicited
address-guessing connections to our servers.

So, in essence, Verizon is not doing sender address verification.  They're
instead attempting what looks like nothing more than a dictionary attack
against our servers.

After a certain number of bogus address attempts, this escalates their
blocklist entries to the firewall, by design trumping all whitelisting they
might otherwise have been granted.

The end result is they have, by design or incompetence, totally shut down
mail to their users from those not-spam networks who have to generally
block address-guessing attacks and the ongoing spam load emanating from
Verizon's networks.

> haven't easily found any.

The BCP is:  Don't try to do sender address verification.  You almost
certainly can't do it right.

Even if you don't make Verizon's very braindead mistakes, you can't connect
out-of-band from the original SMTP connection and hope to retain or
regenerate enough state to tell whether a given FROM and TO pair of IPs and
email addresses will work symmetrically.

Richard

---

From: Florian Weimer <[email-masked]>
Date: Sun, 13 Mar 2005 19:20:57 +0100

* Dennis Dayman:

> They setup a wildcard account for west.verizon.net on the mail
> system in case the remote host performs Sender Verifications checks.

Which is a bit pointless if you block 25/TCP traffic to this host form
most parts of the educated world. 8->