techblog 

Having moved over to our IronPort MTAs we have discovered that some people were no longer accepting delivery of some of our messages. The major symptom of this showed up in the logs as “[Errno 54] Connection reset by peer”

After a bit of searching we found one log entry where there was an error message generated by qmail which pointed to a URL that actually redirects to http://cr.yp.to/docs/smtplf.html. This very useful page explained that some MTAs send messages with lines terminated by a bare LF instead of the required CR + LF pair. One MTA identified as doing that is the IronPort.

A search on the IronPort KB (the one with ridiculous password protection) throws up an article which states:

“IronPort believes that a messaging gateway appliance should be as transparent to the messaging flow as possible and does not reject or repair messages with bare <LF> characters. This means that the behavior of the final destination messaging system with regard to improperly formatted messages (such as those with bare <LF> in them) will override. In other words, if bare <LF> messages are allowed by the destination messaging system, then AsyncOS will not block them. If bare <LF> messages are not allowed, then these will be bounced back to the sender by the IronPort appliance.”

So that narrowed the problem down to some processes at our end that were sending emails with bare LF line terminators. These turned out to be mails generated using the Oracle mail package, possibly where the body of the mail was copied from a Unix text file.

Interestingly these problems never appeared when the MTA was Postfix. It turns out that Postfix was doing some silent fixing of the bare LFs and replacing them with CR + LF pairs.