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-14 by Gary Aitken

Hi Eugene,

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

By throttling you simply mean extend the greylist delay, correct?
It's not clear to me that this will have any effect in the end,
until one gets to reject (5xx).

If we assume a compliant sender, then it will look and behave
completely valid and eventually we will be forced to accept the
mail unless it makes it to the blacklist.  Although the resources
necessary for a retry over a long period will obviously be larger.

Presumably if one determines complete blocking with 5xx, then one
also submits to an rbl?  Or must one also maintain a local rbl
with addressee specific info?

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

These need some means of seeding them with info if the server
is known to emit good mail, even though no mail from those
sources has yet been received.  In some cases, it may be a
long time before good mail arrives from one of these sources,
and they may be sources of spam as well.

> - intensity of the flow of submissions
> - percentage of submissions to non-existant users
> - intensity of submissions to honeypot addresses

I really like this one.  The system could be given
the location of a local web page and a template for rewriting it,
and rules for generating email addresses.  It could periodically
rewrite the page and tune accordingly.  The advantage over other
sources is that it is guaranteed spam.  Cross-referenced to
something like DCC it could be very effective in rejecting spam
to legitimate users.  The disadvantage is the obvious time
delay before the honeypot starts receiving mail.

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

Isn't this what DCC does already on a per-message basis?

If not, I don't see how this is particularly useful.  How do you
differentiate valid mail from that server?  It seems to me there
is a very high probability for valid mail being rejected.  Or were
you just lucky and had no valid mail from that server?

Again, a correlation with DCC info would significantly
improve the validity of the results.

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

I'm not sure I understand this.  If it is not retried, it is
effectively blocked on the particular receiving site, but shouldn't
this information be added to the rating in case they upgrade and
begin to retry?

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

Certainly a worthwhile effort, and something to keep in mind for the
design.  I would initially keep it as simple as possible to allow
an implementation that works locally to be easily built.  Abstract
out the communications layer and you should be able to generalize it
to multiple MTAs without impacting anything else, I would hope.

> OK, enough for today.
> Now you tell me how stupid/whishfull thinking I am...

I think it has potential.
When do I get to try it? :-)

Gary

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.