On Tue, Aug 04, 2015 at 01:05:39PM +0200, Patrick Ben Koetter wrote:
> The speed_adjust option for smtpd_proxy_options has a nice side effect. It
> effects how Postfix logs delays "a" (a = time from message arrival to last
> active queue entry). That's an important feature (to us), because we have SLAs
> where the time spent within the MTA must not exceed a certain time.
>
> If I don't enable speed_adjust Postfix will also account the time spent
> receiving mail from e.g. slow sending clients. The sending speed is something
> we can't control. But it influences the overall time a message seems to have
> spent in Postfix. And this leads to problems with SLAs.
The "a" time starts when the queue file is created (empty). With
proxy filters and speed_adjust, the queue file is created by the
after-proxy SMTP service only after the before-proxy SMTP service
receives the complete message (because the message is buffered).
> How does Postfix handle "a" when used in combination with a MILTER? I
> assume - without any testing - it will also account the "client factor".
Milters don't delay queue file creation. You can if you like (at
the cost of increased disk I/O load) run the mail through a "null"
proxy (just forward from one smtpd(8) to another smtpd(8) with no
actual proxy in between) and enable the milters in the back-end
SMTP service. Then the clock again starts when the message is
received.
With good log analysis, and sufficiently large active queue limits
(memory is much larger these days than in 1997) you might also
start the clock from the first "qmgr" entry for a message, but that
requires looking further back in the log.
--
Viktor.
