anti-spam tests...

[Matti Aarnio <mea@nic.funet.fi>]

(lets begin a new thread, although it relates to what is been
 talked about)

One way to combat "proxy-hijack" identity hiding is to verify, that
the source system does not have open SOCKS/HTTP-CONNECT proxy.

How to do that ?

A concise way would be to contact the IP address at a bunch of
test ports (880/8008/8080/8081/squid), and issue there a CONNECT.
Try it with your local connect-proxy ("https"-proxy):

  CONNECT 2.2.2.2:25 HTTP/1.1<enter>
  <enter>

where "2.2.2.2" is your local smtp-server's IP address.
You should get a few responses from the proxy, and then your
smtp-server replies.

Something like    http://monster.cyberabuse.org/   tester:

     There are 8 steps in the process (10 seconds max for each).    
     Scan of 62.240.94.4 in progress...
     SCANNING FOR A MISCONFIGURED WINGATE PROXY (PORT 23).              
     SCANNING FOR A MISCONFIGURED SOCKS 4 (PORT 1080).
     SCANNING FOR A MISCONFIGURED SOCKS 5 (PORT 1080).                  
     SCANNING FOR A MISCONFIGURED HTTP PROXY (PORT 80).
     SCANNING FOR A MISCONFIGURED HTTP PROXY (PORT 81).              
     SCANNING FOR A MISCONFIGURED SQUID OR WINROUTE PROXY (PORT 3128).
     SCANNING FOR A MISCONFIGURED HTTP PROXY (PORT 8000).     
     SCANNING FOR A MISCONFIGURED HTTP PROXY (PORT 8080).               
     Scan of 62.240.94.4 is complete.

To avoid deadly embraces, the testing code needs to maintain
cluster-wide statistics (possibly be a server of its own),
when it begins testing (before the first connect), it needs
to mark that address is in testing, and subsequent questions
(caused by the test itself) get back an "ok" state.

Possibly the smtp-server should always respond with the normal
greeting, and only then call for the block-proxy-detector.
To speed things up, the detector could be kicked (asynchronously)
to find the answer before the 220 greeting, but actual state of
the data is asked only afterwards.


Only when the tester knows for sure that there is an open proxy,
it will begin to yield a "reject" info causing all MAIL FROM/RCPT TO
commands in the session to fail.

Caches are needed too, negative one ("ok") for at least an hour,
positive ("reject") perhaps several hours.   Possibly the positives
can have some "retest positive again, increase the time quanta"
method.  Persistent database, logs, all that..


Of course such scanners will cause occasional complaints from people
who detect their probes.


-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi