> On 07 Apr 2021, at 14:35, Ralph Seichter <ra...@ml.seichter.de> wrote:
>
> * Wietse Venema:
>
>> What problem are you trying to solve?
>
> Milters A, B and C in my example scenario can trigger asynchronous
> actions in backend systems, the results of which become available only
> after a delay caused by processing, which takes about 3 minutes. These
> results are required by milter D, and it is not feasible to have Postfix
> hold the original sender's session in an active state for this amount of
> time.
>
> My idea is to hold the affected messages in a FIFO-queue-like component
> for a configurable amount of time, long enough to ensure that the
> backend processing has finished when milter D is called. Other than
> inducing a delay, the transport queue can be "dumb". That whay, I see no
> need for any form of synchronisation between Postfix and the third-party
> backend processes.
I think you would have to create your own quarantine queue to hold those
messages and then have D act as a content_filter (not a milter) then re-inject
them into the postfix queue. I believe ClamAV does something along these lines
though the reinfection¹ requires user interaction in that case.
But if your are spending MINUES looking at a mail message might I suggest that
is where your problem lies?
¹ Reinjection, but it was too funny to edit out :)
--
Si Hoc Legere Scis Nimium Eruditionis Habes
