Milter-greylist

egcrosser <egcrosser@...> wrote:

> 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 :-)

Yes, I beleive that.

Hum... I'll work on introducing stupid bugs to prevent large scale
deploying of milter-greylist, just in case :)
 
> - 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

You omit honeypots. Is it on purpose? A good set of spam trap addresses
is a very simple and efficient way of detecting zombies. 
 
> 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.

Did you have a look at http://ftp.espci.fr/pub/dst ?

It's a real-time spam trap system. The idea is to set honeypots
addresses and to publish the addresses (on a web page, in an HTML
comment, for instance: <!-- spamtrap20041214@... -->. You can
also post in the news and have it in your headers)

Spambots will collect the addresses and spammers will send spam to the
addresses. Here you have a very important property: you know that any
mail sent to such an address is spam.  

But knowing someone sent some spam is not enough. Spammers can
distribute the attacks on their zombies army, and use a different IP
address for each spam they send to your domain. So we need a way of
quickly distributing the information that a message was dropped in a
spam trap. If the spam trap are largely distributed, then you'll be able
to know about a zombie as soon as it sends a single mail to any machine
participating to the spam trap network.

DST (Distributed Spam Traps) try to acheive that. It works with two
pieces:

dstc is meant to be installed on a mailbox (you use a .forward and pipe
mail through it, for instance). It reads the headers, looking for the
sending machine IP. It then sends RSA signed report to the nearest dtsd

dstd is a daemon. It exchanges spam reports with neighbourg dstd exactly
in the same way as NNTP works: the report is a small RFC822-like
message, with a Message-Id and a Path header to avoid loops.

dstd can log reports, it can verify the RSA signature, and it can feed a
DNSRBL through DNS updates. 

The key points are:
- you get a real-time notification to many machine for one spam 
- that works with any MTA (I assume any MTA supports DNSRBL)
- there is no single point of failure: spammers can DDOS to death a site
and DST will still work

I halted developpement a long time ago because it was not useful at the
moment, but we could consider working on it now. There are a few issues
that should be worked on:

1- Large deployement means key management problems. The public key
should probably be sent with the report and stored in a pending keys
directory, so that the administrator can decide to add the key of a new
site. That seems the simplier to me.

2- What should be done with the information. One counter attack from
spammers could be to identify a spam trap and use zombies to send
messages there through many ISP mail server. The ISP mail servers being
blacklisted by the DST, it becomes completely poisoned, and therefore
useless. In order to avoid that, we just have to change spamtraps
addresses often. Your ideas about varying greylisting time could help
solving that problem too.

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...