[milters] Archive

Lists Index Date Thread Search

Article: 1691
From: Ulf Bahrenfuss
Date: 2007-09-13 08:09:03 -0400
Subject: AW: Sharing milter-ahead greylist?

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support

That would be a fine feature also in milter-sender....

Currently we are using milter-greylist from another author that does exac=
tly this. We are syncing multiple servers with the greylister.... Works g=
ood, but we do greylist almost everyone (except the rare verified TLS con=
nections and some systems with queue problems). Our multiple servers are =
also in a load balanced configuration.

Caveat emptor:
Not everyone has the luxury of middle and higher management taking the bl=
ame for delays and possible false positives (I have that in writing from =
our C-level execs and they were backing that the last three years against=
  even the greatest fire from other departments. We only get problems, if =
to much spam comes through). And there are many systems out there, that d=
o not cope well with greylisting. That ranges from long retry times (90+ =
minutes) to insane reactions to a 4xx error code: Either 3 retries to bac=
kup MX or the main system within a few seconds and then DSN-ing the Mail =
to flood retries until the greylist time is over. The current record hold=
er made about 10k connections in 2 minutes. Made a nice spike on the grap=


-----Urspr=FCngliche Nachricht-----
Von: milters-bounce@milter.info [mailto:milters-bounce@milter.info] Im Au=
ftrag von Christopher Lindsey
An: milters@milter.info
Betreff: [milters] Sharing milter-ahead greylist?

Is there any mechanism in place to share the milter-ahead greylist across
multiple servers or use other storage mechanisms?

Having a greylist option like the MxCallAheadDb feature would be
invaluable in our situation -- we have three servers answering email
in a round-robin from the outside world, so if one system adds an entry
to the greylist another system will add that entry to its own greylist
instead of accepting the message.  In a worst-case scenario, it could
take four tries before an email that was greylisted could get through.

Using a shared data source would obviously remedy this, allowing greylist=
to work on the second attempt like expected.

Also, is there any way to have milter-ahead just add a header or somethin=
instead of blocking a message outright?  Being able to score based on=20
headers in spamassassin is preferable because of user customization.

I'm not adverse to writing any of these patches myself if they're conside=
worthwhile, either.  But if these are already planned or accounted for,=20
why bother?  ;)



Christopher Lindsey          Technical Program Manager
National Center for Supercomputing Applications (NCSA)

Lists Index Date Thread Search