Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] Re: Another idea for rating system

2004-12-16 by manu@netbsd.org

egcrosser <egcrosser@...> wrote:

[DST]
> 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.

Sure. One of the problems is spam sent through an ISP mail server.
Indeed there is the need for something smarter. 

I think about adding more information in the DNSRBL, such as a spamming
score for a given machine, but in order to do something useful, we need
to collect spam patterns from the real world. That's why I call for an
experimental deployment of DST. 

Once we'll have 100 reports per hour (with only one spam trap, I already
get a lot of spam each day), it will be easier to invent a scoring
system.
 
> If we want gradations of black and white, DNS query/update machanism
> that you currently use in DST may not be adequate...

You can store many informations in the DNS. You can have a score in a
TXT record. 
 
> 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.

I agree here, rejection should occur at SMTP level whenever it is
possible. The Internet will move toward that, but I won't 
 
> > 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.

Give score to reporers, with higher score to more trusted ones.
Intrusions are not a real issue, however. The spammer can use an army of
compromised hosts to target a spamtrap through ISP mail servers,
therefore poisoning the DST. We need a mecanism to address that. Maybe a
spamtrap should be closed after enough hits, or something like this.  

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

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.