No doubt about that. We get thousands of Verizon zombies connecting
to us every day. SenderBase.org shows 25,300 zombies active in the
last 30 days that start with "pool" and end with verizon.net.
Regarding Sender Address Validation in general. I believe this is
effectively the equivalent of Challenge/Response-lite.
is that something real or a made up phrase. google doesn't know it.
I already receive about 100,000 bounces to bad addresses per day
that are backscatter from systems that accept messages without
validating the recipient or who have broken forwarding.
backscatter is a real problem, but has nothing to do with SAV.
If everyone was to start to use SAV, could you imagine how many
connections my system would be receiving each day from all the
forging and dictionary attacks that go on?
SAV should be done very selectively and last after all other filters.
the negative/positive SAV probe results should be cached.
My guess is that this would increase my connection traffic by at
least 10 times. If such a thing isn't appropriate for everyone to
use, why should it be appropriate for anyone at all?
opionions vary :)
My mail servers are not there for Verizon to block their spam with,
nor anyone else that wants to use SAV.
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?
1,394 compares to how many total msgs to your mail server, how many
were SPAM that you accepted/queued/scanned then deleted or
quarantined? ie, what was the increment of work to your mailserver
by Verizon SAV probes.
An SAV probe stops after the RCPT TO:, is probably 200 bytes total
transactions, taking under 2 secs.
In looking at some newsgroups, I found that in at least November and
December, they were sometimes connecting from IP's that had no
reverse DNS entry. While that doesn't cause us issues, that results
in some rejections of their probes by many gateways. I also found
this list of instructions from their support:
1.) Please ensure that your server is accepting mail from 206.46.252.0/24.
those are the "pub" PTR I mentioned in this thread:
for yesterday, our MXs saw these "qty connects from the PTR, PTR
[ip]" in that Class C:
36 sv10pub.verizon.net[206.46.252.146]
137 sv11pub.verizon.net[206.46.252.147]
126 sv12pub.verizon.net[206.46.252.148]
130 sv13pub.verizon.net[206.46.252.149]
145 sv14pub.verizon.net[206.46.252.150]
122 sv15pub.verizon.net[206.46.252.151]
124 sv16pub.verizon.net[206.46.252.152]
122 sv17pub.verizon.net[206.46.252.153]
112 sv18pub.verizon.net[206.46.252.154]
139 sv19pub.verizon.net[206.46.252.155]
145 sv1pub.verizon.net[206.46.252.137]
116 sv20pub.verizon.net[206.46.252.156]
128 sv21pub.verizon.net[206.46.252.157]
127 sv22pub.verizon.net[206.46.252.158]
124 sv23pub.verizon.net[206.46.252.159]
142 sv24pub.verizon.net[206.46.252.160]
113 sv25pub.verizon.net[206.46.252.161]
154 sv26pub.verizon.net[206.46.252.162]
129 sv28pub.verizon.net[206.46.252.164]
131 sv2pub.verizon.net[206.46.252.138]
128 sv3pub.verizon.net[206.46.252.139]
146 sv4pub.verizon.net[206.46.252.140]
141 sv5pub.verizon.net[206.46.252.141]
107 sv6pub.verizon.net[206.46.252.142]
76 sv7pub.verizon.net[206.46.252.143]
113 sv8pub.verizon.net[206.46.252.144]
122 sv9pub.verizon.net[206.46.252.145]
2 vms039pub.verizon.net[206.46.252.39]
95 vms040pub.verizon.net[206.46.252.40]
1 vms041pub.verizon.net[206.46.252.41]
77 vms042pub.verizon.net[206.46.252.42]
87 vms044pub.verizon.net[206.46.252.44]
4 vms045pub.verizon.net[206.46.252.45]
87 vms046pub.verizon.net[206.46.252.46]
2 vms047pub.verizon.net[206.46.252.47]
107 vms048pub.verizon.net[206.46.252.48]
1 vms049pub.verizon.net[206.46.252.49]
1 vms050pub.verizon.net[206.46.252.50]
1 vms051pub.verizon.net[206.46.252.51]
7 vms053pub.verizon.net[206.46.252.53]
7 vms055pub.verizon.net[206.46.252.55]
27 vms115pub.verizon.net[206.46.252.115]
12 vms123pub.verizon.net[206.46.252.123]
2.) Please ensure that your server accepts a Null Mail From:
command e.g. Mail From:<>.
probably null sender is a bad choice for SAV sender, but perfectly legal.
3.) Please ensure your mail server responds to the SMTP commands
within 30 seconds.
The RFC suggests that 3 minutes 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.
... is spam's problem, not SAV, is the slow mailserver's problem, not
SAV. If an MX is so overwhelmed that it can't pickup the phone in 30
seconds and proceed through an SMTP dialog with only a couple seconds
delay between command/response, it has MUCH bigger, more pressing
problems than SAV probes.
if you send from a server protected by SAV to another server
protected by SAV, it is possible that your servers will both demand
the other verify their own address.
One advantage of SAV probes using null sender is that the target
machine can't do its own SAV probe of a null sender.
Two machine reciprocating SAV is not a deadly embrace, and happens
only for the initial contact between the two machines (assuming they
cache the results)
After all is said and done, and if you fail their SAV, you reach
some sort limit with them and they blacklist your domain automatically.
Not clear what you mean. If YOUR outbound is sending lots of
messages to Verizon that fail SAV back your MX, then your outbound is
at risk of being blacklisted at many MXs, not just at Verizon.
I'm well aware of the "religious war" pro/con about SAV and for
greylisting. Both sides are "right", pick your side. :)
Len
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/
