>>>Were all other messages to the same domain similarly delayed? When congestion occurred, all other messages to the same domain were similarly delayed. The delay are longer and longer (the longest exceeded 1200 seconds) and the length of active queue is longer and longer (get to know from the outputs from commands 'qshape active' and 'mailq |grep \* |wc -l, the queued messages were over 9,000).
All outbound emails will be sent to FOPE (one windows antispam system) for scanning. The destination domain is mail.us.messaging.microsoft.com. >>> What is the complete set of logs for this queue-id? Apr 28 10:47:11 cio-krc-pf03 postfix/smtpd[31853]: 9934181190: client=cio-tnc-ht06.osuad.osu.edu[164.107.81.171] Apr 28 10:47:11 cio-krc-pf03 postfix/cleanup[31859]: 9934181190: message-id=<27520027.166481398696426625.javamail.erequest.do.not.re...@osu.edu> Apr 28 10:47:11 cio-krc-pf03 postfix/cleanup[31859]: 9934181190: warning: header Subject: eRequest Submitted from cio-tnc-ht06.osuad.osu.edu[164.107.81.171]; from=<erequest.do.not.re...@osu.edu> to=<turek...@buckeyemail.osu.edu> proto=ESMTP helo=<CIO-TNC-HT06.osuad.osu.edu> Apr 28 10:47:11 cio-krc-pf03 postfix/qmgr[31812]: 9934181190: from=<erequest.do.not.re...@osu.edu>, size=1905, nrcpt=1 (queue active) 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) Apr 28 11:03:18 cio-krc-pf03 postfix/qmgr[31812]: 9934181190: removed >>> How many recipients did this message have? Only one. >>>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). Today 10:00:00 ~ 10:29:59 the output rate of email to this domain in the 30 minutes was 15,361. Today 10:30:00 ~ 10:59:59 the output rate of email to this domain in the 30 minutes was 28,827. Today 11:00:00 ~ 11:29:59 the output rate of email to this domain in the 30 minutes was 111,27. >>> Have you configured any concurrency controls or rate delay for this >>> destination? No. keep default unchanged. Which parameters for concurrency controls or rate delay need to be checked? >>> 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). The IP is old IP. It has been used for 1.5 years. >>> 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. How can we increase delivery rate so that b-delay is down? >>>There is no reason to expect that TLS has anything to do with this. >>>Why are you sending TLS settings? Security department enforces us to turn on TLS. I just provided TLS settings for reference. If no use, just ignore it. Sorry! >>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. How can we check the new server has a working local DNS cache? Check the file /etc/resolv.conf? The server IP reputation should be good, never gets blocked. In peak hours 10:30:00~ 10:59:59, other servers running Postfix-2.6.6 on RHEL 6.4 were fine. Only this server running Postfix-2.6.6 on RHEL 5.10 experienced serious delay. Do we need change some parameters to increase delivery rate or set special channel/allocate fixed SMTP processes for specified outbound domains? Our outbound emails have four main destination domains to be relayed to Windows FOPE. Buckeyemail.osu.edu ---------------> mail.us.messaging.microsoft.com Gmail.com ---------------------------> mail.us.messaging.microsoft.com Yahoo.com ----------------------------> mail.us.messaging.microsoft.com Hotmail.com ---------------------------> mail.us.messaging.microsoft.com Thanks, Carl -----Original Message----- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Viktor Dukhovni Sent: Monday, April 28, 2014 12:17 PM To: postfix-users@postfix.org Subject: Backlog to outsourced email provider 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.
