Sorry for the delay.. > > >> >> Could you explain - in the same terms - how is quantified the > time > > >> >> before > > >> >> a message is passed to the queue manager, after it is processed > by > > >> the > > >> >> content filter? > > >> > > > >> > The time to deliver is measured as the time between MAIL FROM > and > > >> > "end-of-data". > > >> > > >> Sorry for my bad english.. To be clearer, given "delays=a/b/c/d" I > asked > > >> for the meaning of "a" delay. I need this definition to understand > > >> better > > >> the difference of time between "d" in 1) and "d" in 2) in the > example > > >> above. > > > > > > Citing from the HISTORY file: > > > > > > The information is now logged as "delays=a/b/c/d" where > > > a=time before queue manager, including message transmission; > > > > > > a=time from MAIL FROM until queue manager. > > > > Ok, Wietse so considering my example: > > > > 1) Jan 30 10:02:17 av5 postfix/smtp[10603]: C0AFB226F23: > > to=<recei...@domain.tld>, relay=127.0.0.1[127.0.0.1]:10026, > delay=8.9, > > delays=1.3/0/0/7.7, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as > > 95CEE226F30) > > 2) Jan 30 10:02:17 av5 postfix/smtp[5441]: 95CEE226F30: > > to=<recei...@domain.tld>, relay=server[xxx.yyy.zzz.uuu]:25, > delay=0.11, > > delays=0.03/0.04/0.01/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: > queued > > as 5C7951098002) > > > > and that: > > > > i) There are 7.7 seconds between the time that the Postfix SMTP > client > > sends the MAIL FROM command to the filter, and the time that the > > filter sends the end-of-data reply to the Postfix SMTP client. > > > > ii) a=time from MAIL FROM until queue manager = 0.3 in 2) > > No, "0.03" not "0.3". > > > Indeed, I thought (wrong) that they was the same transmission (and I > > cannot justify it because there was an evident timing difference - > 7.7 and > > 0.3). > > The filter is likely buffering the SMTP dialogue, and not initiating > the downstream connection until it has processed the data. > > > Instead, i) is the transmission from Postfix to the content filter, > while > > ii) should be the reinjection of the message back to the "normal" MTA > > flow. > > This happens when filters buffer the envelope, not just the payload.
A last trivial question on this argument.. In a such configuration (Postfix+Amavisd-new), is the total latency of a message from the time it is transmitted from the client SMTP to the time the receinving MTA sends "end-of-data", given by summing the delay 1) and 2) reported above? Thanks, rocsca
