Ralph Seichter:
> * Wietse Venema:
>
> > Perhaps better, Milter D defers the message immrediately, and Postfix
> > retries a few minutes later, until the necessary data is available.
>
> Indeed. Having milter D block until the required data becomes available
> would tie up too many resources. Better to make D reply with 4xx and to
> have Postfix invoke its back-off strategies.
>
> The downside is that changes to milter D would be required, which
> happens to be third-party software. It currently relies on the necessary
What does the milter do when data is unavailable?
> data being already available when called. Hence my idea to introduce
> some form of transport that adds a long enough delay to ensure that the
> data is actually present when D is called.
You could put a sleep(500) call in the content filter.
network -> smtp(milters A-Z) -> cleanup(milter_header_checks) -> queue
No magical milter header:
-> queue -> delivery as usual
With magical milter header:
queue -> smtp(long timeouts) -> proxy(with sleep 500) ->
smtpd(milter D, long milter timeouts) -> queue -> delivery as usual
The proxy sleeps and relays the inputs and outputs from the
smtp and smtpd processes.
Wietse
> Still, I have asked the authors of milter D if they would even consider
> making any changes; an answer is pending.
>
> -Ralph
>
