Milter-greylist

OK, I'm back from hacking an antivirus module for zmscanner, and full
of sh^H^Hthoughts.  Maybe too global for this project, maybe not.

First, I think that I must better introduce myself.  On the dayjob, I
am a sysadmin team leader at large, and a postmaster in particular,
for a big isp in my country.  We do not run sendmail.  And we do have
a home-grown spam-supression tool which is very similar to
greylisting.  Aside from that, I am running sendmail on several
small/private sites, with milter-greylist on one of them.

Now when I am thinking about antispam solution, I am equally concerned
about my small and big systems.  Being a big ISP means being a target
of choice for spammers.  It means that if I leave a *potential* hole
in the system, bad guys find it and start using it within a couple of
weeks.  Good antispam solution design should not allow that.

For greylisting approach, "worst case" scenario is an army of zombies
that can retry after 4xx.  And this will happen very soon after any
big ISP deploys greylisting.  You can trust me on that :-)

That's why I think that grelisting per se can be only a temporary
remedy.  But combined with other means, it's a different story. 
Greylisting's strong point is that it's protection starts instantly as
an attack begins.  It's weak point is that it quickly gives up as the
attack continues.

On the other hand, reputation systems (including blacklists and
whitelists as their extreme form) gradually grow stronger with time,
but cannot catch a sudden attack.  So, it seems worth to try to
combine the two approaches.  Greylisting will slow down a new attack,
and feed data to a reputation system.  Then it turn, it can consult
the reputation system and set "level of throttling" according to the
rating of the peer.  Up to complete blocking with 5xx code.

Now to the reputation system.  It probably will be best if it collects
rating data from a number of different sources, with different
weights.  Things that come in mind are:

- intensity of the flow of submissions
- percentage of submissions to non-existant users
- intensity of submissions to honeypot addresses
- for SPF-validated submission, age of the domain
- for back-resolvable peer address, fuzzy check against typical
dualup/dsl/cable patterns, and against typical valid mail server
patterns (we found this one particularily useful here)
- not not back-resolvable, the fact that they are not back-resolvable
- intensity of DCC positive submissions

(my previous idea that non-retried greylisted peer should grow
negative rating is not very useful: mail from it is blocked anyway)

Now, a reputation system is the better the more MTAs it serves.  I
don't beleive in worldwide reputation systems but corporation-wide
seem realistic.  So it should have some simple network interface, with
strong enough access control to disallow poisoning.  DNSBL style? 
Note that it should be able to accept updates from different sources
and  give them different weights.

OK, enough for today.
Now you tell me how stupid/whishfull thinking I am...
:-)
Eugene