AOL is apparently defending itself, dynamically, against dictionary 
attacks, in a similar manner to my advanced scripts for IMGate, by blocking 
IPs that send above a threshold messages to unknown AOL users.

The problem with SAV is that when your IMGate is receiving msgs from forged 
AOL senders and your SAV is trying to validate them at AOL's MXs, SAV might 
trigger the threshold at AOL and get your MX blocked, since AOL can't 
distinguish between your SAV proves and a dictionary attack.

A difficult situation since SAV is very effective in stopping forgeries of 
AOL (which AOL can't be against).  We don't know what AOLs threshold is, 
but if it's high enough, then SAV will perhaps not get caught.

This is exactly the same weakness with my scripts.  They detect a threshold 
of rejects from an IP of a legit org like Earthlink, and block the IP, 
thereby blocking all legit mail from the Earthlink IPs.  If you whitelist 
the Earthlink IPs, then you open yourself up to tons of spam.  Ironically, 
it was SAV that relieved this situation, giving us a more precise tool for 
distinguishing between legit mail from verifiable Earthlink users and IPs 
from spam from forged senders from an Earthlink IP.

Another situation is when you are getting a dictionary attack from forged 
AOL senders, and SAV is your first defense, then SAV will probably get in 
trouble at AOL.  But you should not be using SAV to defend against 
dictionary attacks, but rather check_recipient_maps near the top of your 
restrictions.

If we whitelist AOL's outbound IPs before SAV, then we open ourselves up to 
being spammed by AOL users from AOLs outbound IPs.

I'd like anybody who gets blocked by AOL due to SAV probing or who has an 
approach that could fix this problem to keep the list informed.

Note that if AOL implemtend DMP, then you could credibilize your MXs at AOL 
via DMP, allowing AOL effectively to whitelist your MXs, or have a 
two-threshold block, where DMP domains would have a higher thresholds.

thanks
Len


Reply via email to