Milter-greylist

--- In milter-greylist@yahoogroups.com, Gary Aitken <greylist@d...> wrote:

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

General idea is to accept spam and mail from anyone (except those with
very bad reputation), but make the job harder (bigger delays, higher
chance of reject) for those who send more spam than ham.  If a site
sends only spam, it will end up with very bad reputation and
eventually will be blocked.  If it sends good mail, and almost no
spam, its reputation will grow good, which is equivalent to
whitelisting.  The owners of sites that send both spam and ham will
get complains from their users, and have overcrowded outgoing queue,
and thus get incentive to put more pressue on their spammers.

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

Essentially, reputation system is a (better) replacement for RBL. 
Reputation that is lower than a defined threshold means blocking.

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

Not necesserily.  Initial "default" reputation may be good enough to
impose only a small greylisting delay.  It also may be seeded by
reverse DNS and/or whois inspired guesstimates.

On our production system, we always instantly accept first submission
from an unknown source.  They may have harder time to push the next
one, depending on a number of conditions.  I am not completely
satisfied with the performance (and that's why I am here:), but it
keeps junk at more or less tolerable level.

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

By DCC I mean generic thing that recognizes repeating patterns, not
the particular implementation from riolytte(sp?).

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

The chance of getting valid mail from p123-nas45.dsl.isp.net is close
to zero.  If someone tries to install a real SMTP server on the end of
a DSL connection he is just unlucky.  If he really must, he can use
SPF, for some time suffer from big delays, but eventually get his
reputation improved and live happily ever after.

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

That's true.  Although it probably should be DCC's responsibility to
distinguish generic reports from reports from honeypots and give the
latter more weight (again, I mean hypothetical DCC here).

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

Well, maybe.

Eugene