Milter-greylist

--- In milter-greylist@yahoogroups.com, manu@n... wrote:

> > 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 ?

I did download the thingie and read the docs.  I confess that I did
not try to build it though :-)  Anyway, when I realized that you
already have two important elements of the model that I was mulling I
decided to climb up the soapbox.

Anyway, your system presumes "binary" rating: if a honeypot address is
hit, the sender is blacklisted for good.  I think that it is too
dangerous: valid servers *may* eventually send some spam, including
that to honeypots.  For a reputation system with gradations this is
not a problem because good behavior keeps server reputation high, and
a bit of spam just slightly offsets it.

If we want gradations of black and white, DNS query/update machanism
that you currently use in DST may not be adequate...

BTW, answering to Matthias Scheler's concern about bounces being taken
for spam: nowdays many people think that bounces are almost as bad as
spam, and servers that generate bounces instead of rejecting
submissions at SMTP stage deserve that same treatment as spam senders.

> 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.

Large (worlwide) deployment has more problems than just key
management.  First of all, it's about trust.  Even if you trust the
people who run servers, you harly can hope that all of them are
adequatly intruder-resistant.  And if an enemy infiltrates to even a
single node, he may wreak havoc to the whole system.

Another interesting moment is that for a large server, cooperation may
not be that beneficial.  That's because attacks targeted to just one
specific big server are not uncommon.

I think that a protection system design should presume that it can be
deployed in both widely distributed and relatively "local" environment.

> 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.

Yes, I think that we should try to detect both "good" and "bad"
behavior, and adjust reputation accordingly.  This would minimize
impact of accidental false positives and deliberate poisoning attacks
alike.

Eugene