* 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. -Ralph
