On 02/21/2013 03:34 PM, Ralf Hildebrandt wrote:
It could be that the process injecting the mails into the queue is
stalling the queuemanager, thus sending out can only begin AFTER the
injection period.
... how ?
Either pickup(8) or smtpd(8) do the queueing; the qmgr only SENDS mail.
There could be disk I/O contention, sure, but that would never translate
into a scenario where no mail could be de-queued before all mail was
finished queueing.
These are wholly separate processes after all, and the only point of
contact is the mail queue, which is concurrent read-write by design.
By default, there may be many simultaneous processes accessing the queue
(100 each of smtpd and smtp, for starters.)
Of course, it could be that he really is sending every single submitted
message through amavisd and then re-injecting into postfix, thus
effectively forcing every single message through the pipeline twice.
This would be inane no matter what kind of IP address it has, but the
cause of the delays would be the content_filter, nothing else.
There are settings in amavisd-new that govern what to do when a message
originates from a trusted or untrusted IP range, offering the option to
pass it through without scanning.
If this was impacted by the IP change, that could easily explain the
delays - but they would still never be sequential.
Of course, you did ask for logs as well :)
--
J.
