S?bastien Michel:
> We have two options : moving the management of
> smtpd_reject_filter_maps in check_milter_reply with the need to give a
> context into smtpd_chat_reply to not apply smtpd_reject_footer_maps if
> a replacement occured, or other option to merge the handling of smtpd
> error
Le lun. 13 janv. 2020 à 09:59, Sébastien Michel a écrit :
>
> Le dim. 12 janv. 2020 à 21:28, Wietse Venema a écrit :
> > Viktor Dukhovni:
> > > My instinct was to suggest that the filter goes first, and then the
> > > footer gets added, but usability rather depends on how the pending
> > >
Thierry Fournier:
> Hi,
>
> What do you think about delivery target executing natively Lua code ?
>
> It does the same think than ?pipe", but much quickly because there
> are no fork/exec and compile/recompile Lua code only at start (or
> if required).
>
> In other way, the Lua postix API can
> On 14 Jan 2020, at 14:40, Viktor Dukhovni wrote:
>
> On Tue, Jan 14, 2020 at 02:34:42PM +0100, Thierry Fournier wrote:
>
>> What do you think about delivery target executing natively Lua code ?
>
> I don't see a need for this.
>
>> It does the same thing than “pipe", but much quickly
On Tue, Jan 14, 2020 at 02:34:42PM +0100, Thierry Fournier wrote:
> What do you think about delivery target executing natively Lua code ?
I don't see a need for this.
> It does the same thing than “pipe", but much quickly because there
> are no fork/exec and compile/recompile Lua code only at
Hi,
What do you think about delivery target executing natively Lua code ?
It does the same think than “pipe", but much quickly because there
are no fork/exec and compile/recompile Lua code only at start (or
if required).
In other way, the Lua postix API can embed convenience function
like
