Open Relay Checker before Opening MTA

[Alex Satrapa]

On Sunday, February 10, 2002, at 07:41 , Howard Lowndes wrote:

> It founds neat, but I agree about the scaleability issue.

Where do the scalability issues come from?  I'm just "thinking out 
loud" - so I expect to answer my own question, but here's my thinking so 
others can check.

There are only ever two machines involved in the immediate transaction, 
so at worst you will double the load on your mail server.  The other end 
is either going to be getting one more transaction that its normal load 
(the OR test which will fail), or two more transactions than it's 
currently abused open-relay mode load (the OR test which works and the 
OR status notification).

Spam usually comes from mail servers you've never spoken to before.  The 
worst case scenario here is that you're going to be testing every MTA in 
the world.

Hmm.  I would call that a minor scalability issue ;)

Perhaps rather than maintaining a white list and black list, you use the 
MTA OR test as a supplement to an externally maintained black list.  If 
a machine is not black listed on ORBZ or whatever is going these days, 
then do the test.  If the machine passes, add it to a local white list 
which is time-limited.  Don't re-test unless the machine has fallen off 
your local white list.

So the process becomes:
1. Check remote MTA against public black list
      listed: end transaction
      unlisted: continue
2. Check remote MTA against local white list
      listed: continue
      unlisted:
        1. Perform OR test
             doesn't work:
               1. add to local white list
               2. continue transaction
             works:
               1. notify public black list
               2. end transaction
3. Transaction continues...


This way, you're only storing your white list.  The worst case scenario 
here is that you keep a white list of all the MTAs in the world (in the 
unlikely scenario that all the nominated System Administrators in the 
world get a clue and fix their systems) for a short time.

You don't waste space storing your own black list.  Then again, if you 
get repeated transactions from a known-by-spammers but not known-by-ORBZ 
OR MTA, you're going to repeat the OR test.

You also don't waste bandwidth (however small) continually checking 
white-listed MTAs.

So if you are going to do a OR-test and store a local "black list", you 
would end up with Neil's original system as far as remote MTA 
connections are concerned:

1. Check remote MTA against public black list
      listed:
        1. Check remote MTA against local black list
             listed:  remove from local black list (a)
        2. end transaction
      unlisted:
        1. Check remote MTA against local black list
             listed: end transaction (b)
             unlisted: continue transaction
2. Check remote MTA against local white list
      listed: continue
      unlisted:
        1. Perform OR test
             doesn't work:
               1. add to local white list
               2. continue transaction
             works:
               1. notify public black list
               2. notify remote MTA administrator, domain postmaster, etc
               3. add to local black list (c)
               4. end transaction
3. Transaction continues...

The points marked (a), (b) and (c) are where you'd be able to instrument 
the system to collect information like mean-time-between-spams (mean of 
(c.time - b.time)) and mean-time-to-public-blacklist (mean of (c.time - 
a.time)).

I would make the local black and white lists time limited. Rather than 
automatically retesting, I would leave retesting until the remote MTA 
tries to connect again.

Entries on the white list are time limited, and are never "refreshed".  
They have a limited life time, then expire.  Regardless of how many 
times a white-list MTA connects during its white-listed period, it will 
still be retested after a certain time.

Entires on the black list are refreshed every time they are successfully 
used.  They are only removed if no connections have been attempted by 
that MTA for some time, or if the blacklist entry has made it to the 
public black list.  As far as black list TTL goes, I would expect that 
the time would be something more than mean-time-between-spams as 
mentioned earlier, but not much more than mean-time-to-public-blacklist 
as mentioned earlier.

Questions that I can think of now are:
1) how long do you wait to figure out that the OR test has detected an 
open relay?
2) Is OR status confirmed by the remote MTA accepting your illegitimate 
message, or only by the remote MTA actually delivering your illegitimate 
message?
3) How long do you keep entries on the white list?

Alex