Why is my i/OS Email Coming Back Undeliverable?
April 27, 2011 Hey, Joe
We send a lot of emails from our i 6.1.1 partition using the operating system’s SMTP server and a third-party email application. We recently converted from paper to email invoices, which has resulted in a big spike in System i email. Now we’re also seeing more messages returned from our external SMTP relay as “undeliverable.” What’s going on and what can I do about it? –Glen Given the increased traffic, it looks like your external SMTP server is being overwhelmed with email demands and that is delaying delivery. The external server may simply be busy and not able to handle your mass emails. If delivery is delayed long enough, your i/OS SMTP server will exceed its retransmission parameters for delivery and it will simply stop delivering email to the external server. To combat these time-outs, here’s a quick solution for improving the odds of getting your email delivered. On your i/OS partition, check your SMTP retransmission parameters to see if you’re allowing enough time to send out your newly generated email messages. All SMTP servers have first- and second-level retransmission parameters that tell your iSeries, System i, or Power i server how long to attempt forwarding email to an SMTP relay before the partition gives up and marks the message as “undeliverable.” If you’re using your partition’s default SMTP retransmission parameters, the server attempts to deliver email according to the following rules.
Default i/OS SMTP email delivery is attempted three times over 90 minutes before the system gives up trying to send a message. This isn’t a lot of attempts as opposed to SMTP servers in the non-i/OS world, where email forwarding is attempted over a period ranging anywhere from 12 to 72 hours before marking a message as undeliverable. So one thing you can try is to increase the system’s SMTP server email delivery retransmission parameters to allow for a longer delivery window before a message becomes undeliverable. Start by changing your parameters to 24 delivery attempts over a 12-hour period, with each subsequent delivery attempt occurring every 30 minutes. Doing this will change your i/OS email retransmission schedule from three retransmissions in 90 minutes to 24 retransmissions over 12 hours. With this type of transmission schedule, your email messages have a much lower chance of being marked as “undeliverable” due to a busy SMTP server. Changing your SMTP retry parameters is easy on the green screen. Typing in the following Change SMTP Attributes (CHGSMTPA) command will change your default retry parameter to the 24 delivery attempts in 12 hours scenario I mentioned above. CHGSMTPA RTYMIN(24 30) RTYDAY(0 0) RTYHOUR(0 0) The Retries By Minute (RTYMIN) parameter of “24 30” sets up our 24 delivery attempts every 30 minutes scenario. Notice that there are also Retries By Day (RTYDAY) and Retries By Hour (RTYHOUR) parameters. These parameters are used as secondary retry parameters that backstop RTYMIN when its retries are exhausted. If you’re just setting up the 12 hours every 30 minute scenario, you can safely ignore the RTYDAY and RTYHOUR parameters (setting them to zero) and just set up RTYMIN. Note that SMTP retry parameters can also be set up in System i Navigator (OpsNav). To do this, display all your system’s TCP/IP servers by opening the Network→Servers→TCP/IP node under your partition. Find and right-click on the SMTP server entry in the screen that lists out all the available TCP/IP servers. Select Properties from the pop-up menu that appears. On the SMTP Properties screen, click on the Outbound Mail Retries tab to get the following screen where you can change your SMTP server’s first and second level retry parameters. Whether you are changing your parameters via the green screen or through OpsNav, an SMTP server parameter change takes effect immediately. Delivering your emails over a longer period of time should result in fewer undeliverable messages when the external SMTP server is busy. You can also adjust your retry parameters upward if you find the 24 times in 12 hours scenario does not work for you. HTH –Joe
|