First off, I'm just killing time in the middle of the night while
waiting for some work to complete on a planned upgrade...
Anyway, I do understand these sender validation schemes, but they are a
bad idea in today's world due to the much larger threat of dictionary
attacks. I receive about 25 connections for every good E-mail that my
system passes, and the bulk of that extra traffic are from dictionary
attacks which I don't drop connections until 3 for 3 bad attempts or 5
out of 6, and there is tarpitting after each bad address, so the volume
of bad addresses that we receive to good addresses is just simply
enormous even when throttled greatly. If this traffic was going
straight to IMail, my system wouldn't likely survive.
So it makes sense to have protections in place for abuse like this. On
my system, after 5 connections that get dropped due to passing our bad
address limit, or who only attempt bad addresses, they are then blocked
for either 5 or 30 minutes (I forget which off hand). With IMail 2006's
dictionary attack prevention, once you trigger it, the IP is blocked
until it is removed manually from the ACL.
I still can't recall exactly what Verizon was doing that was causing an
issue, but I am certain that we were not doing anything unexpected.
Their server decided to automatically block Marc's domain on every
message, and without even trying to authenticate against our gateway as
was evidenced by their time stamp. So this was more than just
validating just one address at a time, they were writing off an entire
domain due to their SAV system failing on multiple occasions for
whatever reason. I do believe that the issue was that we may have
greylisted them and returned a 450, and they never retried and they just
decided that that was as good as a bad address or something. The only
way off of their blacklist was to request whitelisting.
Again, I might have some of the facts wrong as I don't have a full
record of the resolution in my E-mail, but I distinctly remember being
perplexed from a technical standpoint by their decision to do whatever
they were doing because I knew that it would have issues far and wide
(like blacklisting domains when they are themselves blocked or
greylisted for trying to validate bad addresses).
I'm sure that they are tickled pink by the massive spam reductions like
most people are when they don't know how to or fail to do the legwork
necessary to show a full picture including the FP's that such a system
creates. They do have a false positive issue and it is their fault.
I however think that SAV could be used in a weighted system...so long as
you weighted it low and didn't test using an IP that you cared about
having blacklisted for even a short period of time. If you were to
selectively target the use of SAV for things that are known to forge,
that might make it more palatable to me. It is a very weak tool though
in comparison to greylisting, and they are both primarily built for the
same thing, i.e. zombie spam.
Matt
Sanford Whiteman wrote:
After they do this on 5 different connection in 5 minutes, their IP
gets automatically blocked by my gateway for clear abuse --
Well, it's the way SAV works (I'm not saying you shouldn't enforce
your policy, but don't be surprised that it has this obvious false
positive, since SAV has been around for quite a while).
and then I might end up blocking all of the E-mail that might come
from this particular IP.
This is the way SAV works, always has. That's why people have
different context- or domain-sensitive thresholds for dictionary
attacks, or they just slow down recipient validation for overly active
IPs using a backoff algorithm rather than blackholing completely, or
they build systems that are capable of massive recipient validation
"attacks" without blinking. Etc. There are also variations in the way
SAV is deployed that can render it quite harmless unless *other*
notable suspect behavior (like rampant fraudulent use of a domain) was
going on as well.
Now for the other way that they might do it. If they are trying to
avoid such systems because this technology makes them look like a
dictionary attacker themselves, they might try connecting back to
the same IP that was connecting to them.
Oh, c'mon. That's preposterous. No one could think that that
constitutes sender address validation. If someone did (utterly in
error) implement such a system in production, the deluge of dropped
mail would force them to flip the system off inside of a day.
One way or another, this is a bad practice.
There is no such practice as the second one you describe.
As for the first practice, it's called Sender Address Verification,
SAV. It's in wide use by Len Conrad, who might chime in to champion
its use in a weighted or otherwise intelligent system (i.e., like when
you employ greylisting only when other suspicious characteristics are
observed). SAV is often set to only call out to frequently forged
domains, which means that a domain that is not commonly Joe-Jobbed
will not see any probes; on the flip side, large legitimate domains
that are well-known to be intolerant of SAV are usually excluded.
Still, when you *are* massively Joe-Jobbed, as was Katie's
centric.net, even a smallish domain can suddenly get promoted to
"frequently forged," and thus receive probes that its infrastructure
may not be able to handle. There are two sides to this: on the obvious
bad side, you may end up rejecting mail due to characterizing a flood
of probes as a dictionary attack to save your systems; on the good
side, this makes you acutely aware that your domain is being used
fraudulently, which is useful information.
I have no great allegiance to SAV myself, but IMO any anti-abuse
tactic that can specifically defuse domain misuse should not be
knee-jerk dismissed. I prefer to build my systems to accept a massive
amount of RCPT TOs, rather than (a) deal with backscatter from the
spam that's needlessly bounced, let alone (b) deal with the confusion
when high-profile spam is sent from just barely nonexistent addresses
at a client's domain (think [EMAIL PROTECTED] vs.
[EMAIL PROTECTED]). But sometimes you can't do the former, so SAV can
obviously be adversarial in those cases. And SAV has no direct effect
on spam sent from extant addresses (though in largely theoretical
concert with VERP-style outgoing envelope tagging, it certainly
could).
--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/
