Milter-greylist

Following patch contains changes below.

http://www.j10n.org/files/mgl-20070328-misc.patch

1. New "%%" syntax in fstring.

2. Clarified "%Xm" and "%Xh" semantics.

3. Fixed a memory leak at mlfi_eom.

4. Fixed the following bug:

% telnet mx.example.org 25
220 mx.example.org ESMTP
MAIL FROM:<black@...>
250 2.1.0 <black@...>... Sender ok
RCPT TO:<black@...>
551 5.7.1 Go away!
RCPT TO:<black@...>
250 2.1.0 <black@...>... Sender ok

As a side effect, the following problem in the comment will revive.

> a wrong X-Greylist header display
> if the {IP, sender e-mail} address was whitelisted and the
> last recipient was also whitelisted.

Anyway, X-Greylist header is just an estimate. No way to make
X-Greylist information accurate no matter how we implement it.
ACL's predictability is much more important than our useless header.

On Thu, Mar 29, 2007 at 01:40:07AM +0900, AIDA Shinra wrote:
> Following patch contains changes below.
> http://www.j10n.org/files/mgl-20070328-misc.patch

I checked it in, but please avoid combo-patches: if something goes wrong 
with one change, I'll have to back out the whole patch.

-- 
Emmanuel Dreyfus
manu@...

Sorry, I broke X-Greylist header when a mail is greylisted and passed:

http://www.j10n.org/files/mgl-20070407-x-greylist.patch

AIDA Shinra <shinra@...> wrote:

> Sorry, I broke X-Greylist header when a mail is greylisted and passed:
> http://www.j10n.org/files/mgl-20070407-x-greylist.patch

Why does that comment has to go away?
        /*
-        * On a multi-recipient message, one message can be whitelisted,
-        * and the next ones be greylisted. The first one would
-        * pass through immediatly (priv->priv_sr.sr_delay = 0) with a
-        * priv->priv_sr.sr_whitelist = EXF_NONE. This would cause improper
-        * X-Greylist header display in mlfi_eom()
-        *
-        * The fix: if we make it to mlfi_eom() with priv_sr.sr_elapsed = 0
-        * this means that some recipients were whitelisted.
-        * We can set priv_sr.sr_whitelist now, because if the message
-        * is greylisted for everyone, it will not go to mlfi_eom(),
-        * and priv_sr.sr_whitelist will not be used.
-        */

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

At Sat, 14 Apr 2007 21:27:19 +0200,
manu@... wrote:
> 
> AIDA Shinra <shinra@...> wrote:
> 
> > Sorry, I broke X-Greylist header when a mail is greylisted and passed:
> > http://www.j10n.org/files/mgl-20070407-x-greylist.patch
> 
> Why does that comment has to go away?
>         /*
> -        * On a multi-recipient message, one message can be whitelisted,
> -        * and the next ones be greylisted. The first one would
> -        * pass through immediatly (priv->priv_sr.sr_delay = 0) with a
> -        * priv->priv_sr.sr_whitelist = EXF_NONE. This would cause improper
> -        * X-Greylist header display in mlfi_eom()
> -        *
> -        * The fix: if we make it to mlfi_eom() with priv_sr.sr_elapsed = 0
> -        * this means that some recipients were whitelisted.
> -        * We can set priv_sr.sr_whitelist now, because if the message
> -        * is greylisted for everyone, it will not go to mlfi_eom(),
> -        * and priv_sr.sr_whitelist will not be used.
> -        */

I missed a point. I focused when a recipient is whitelisted and another
is ACCEPTED after greylisting. The above code focuses when a recipient
is whitelisted and another is GOING TO BE DELAYED.

Anyway, the above code do not work when a recipient is whitelisted
and another is BLACKLISTED. What about this code?

http://www.j10n.org/files/mgl-20070407-x-greylist-revised.patch

AIDA Shinra <shinra@...> wrote:

> http://www.j10n.org/files/mgl-20070407-x-greylist-revised.patch

I checked it in. We'll see how satisfying it is in beta2...

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...