> 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/

Reply via email to