Milter-greylist

> > I guess someone could incrementally try each developement 
> snapshot to
> > between 3.0 and 4.0 alpha to see when things went wrong. But 
> > that's not
> > a funny job. :-/
> > 
> > The other option is to use specialized tools for tracking 
> down memory
> > leaks. Any specialist here? Someone that could perform a 
> > Coverity run on
> > the sources?
> > 
> 
> The attached patch may give a bit more of information about 
> the session in which
> the error may occur.
> 

So here we are:

May 30 19:14:34 mail1 sendmail[217629]: l4UHCKir217629: from=<>, size=10000, class=0, nrcpts=1, msgid=<xxx@...>, proto=ESMTP, daemon=MTA, relay=abc.def [1.2.3.4]
May 30 19:14:35 mail1 milter-greylist: l4UHCKir217629: addr abc.def[1.2.3.4] from <> to <user@...> delayed after DATA phase for 00:02:23 (ACL 1124)
May 30 19:14:35 mail1 milter-greylist: l4UHCKir217629: addr abc.def[1.2.3.4] from <> to <user@...> delayed after DATA phase for 00:02:23 (ACL 1124)
May 30 19:14:35 mail1 milter-greylist: l4UHCKir217629: mg_setreply(): invoked twice
May 30 19:14:36 mail1 sendmail[217629]: l4UHCKir217629: milter_sys_read(milter-greylist): cmd read returned 0, expecting 5
May 30 19:14:36 mail1 sendmail[217629]: l4UHCKir217629: Milter (milter-greylist): to error state
May 30 19:14:36 mail1 sendmail[217629]: l4UHCKir217629: Milter: data, reject=451 4.3.2 Please try again later
May 30 19:14:36 mail1 sendmail[217629]: l4UHCKir217629: to=<user@...>, delay=00:00:08, pri=10000, stat=Please try again later

Since I am using delayed reject option, the code part which triggers the error is this one:

        if (priv->priv_delayed_reject) {
                LIST_FOREACH(rcpt, &priv->priv_rcpt, r_list)
                        log_and_report_greylisting(ctx, priv, rcpt->r_addr);

The log_and_report_greylisting() calls mg_setreply, and there is no smtp_reply_free() in the loop.

Bests,
Attila