On Mon, Apr 28, 2014 at 03:06:16PM +0000, Xie, Wei wrote:
>
> Apr 28 11:03:18 cio-krc-pf03 postfix/smtp[5015]: 9934181190:
> to=<turek...@buckeyemail.osu.edu>,
> relay=mail.us.messaging.microsoft.com[216.32.181.178]:25,
> delay=967, delays=0/964/1.5/1.3, dsn=2.6.0, status=sent
> (250 2.6.0
> <27520027.166481398696426625.javamail.erequest.do.not.re...@osu.edu>
> [InternalId=9787221] Queued mail for delivery)
Were all other messages to the same domain similarly delayed? What
is the complete set of logs for this queue-id? How many recipients
did this message have?
What was the output rate of email to this domain in the 30 minutes
preceeding this log entry? (Avoid counting multiple recipients
with the same queue-id, relay and remote server response as separate
deliveries).
Have you configured any concurrency controls or rate delay for this
destination?
If this is a new IP address sending high volume mail to a major
email provider, it may take time for your "IP reputation" to be
established. During that time it may be prudent to gradually
ramp-up the volume of mail sent by routing a reduced fraction of
your mail via that particular server (less input, not slower output).
> We know about the definition of four a/b/c/d delays information.
> How do we do performance tuning to reduce delay in queue manager?
This delay means a large number of messages waiting behind the
messages currently being delivered, subject to concurrency and
rate delays.
> Here are our configurations about TLS in Postfix configuration
> file /etc/postfix/main.cf. Other default parameters are used. We
> do not change them.
There is no reason to expect that TLS has anything to do with this.
Why are you sending TLS settings?
You need to make sure that the new server has a working local DNS
cache, its IP reputation is good, and your steady-state input rate
does not exceed the output rate of remote destinations.
--
Viktor.
