Exim send failure “421 SMTP incoming data timeout” – Message body lacks ‘\n’ at the end

emailemail-servereximsmtp

I'm trying to figure out how this issue is occurring and how to stop it.
Somehow messages are getting into our inbound Exim spool without any \n
at the end. When our outbound Exim process tries to deliver these mails,
they fail as Exim outputs '.' on the same line as the one it just sent.
I've verified this by capturing the SMTP conversation from both sides
with tcpdump

tcpdump shows the following being sent at the end:

<!–www.https://example.com–><!–www.https://example.com–>.

Which is not a proper termination of DATA. Eventually the receiving MTA responds

421 Lost incoming connection

Passing the message in the spool through od, I see at the end of the message body:

0011700 e . c o m – – >

No \ns. These messages getting stuck in the spool seem to only ever be
spam. What I see in the outbound log,

1NLolk-0003aD-3V == email@example.com R=Storage T=Storage defer (-46): SMTP error from remote mail server after end of data: host 192.168.1.3 [192.168.1.3]: 421 mda.local SMTP incoming data timeout – closing connection.

Does anyone have any ideas? The "message_suffix" parameter sounded like it would have
been a good bandaid, but it only applies to appendfile and pipe.

Best Answer

I consulted with the Exim mailing list on this, and it looks like the problem lies with MailScanner's content filter. We have MailScanner doing virus/spam scanning for us, and it seems on certain messages when it cleans the tail end of a message, \n is left out, and the message is put into the outbound Exim queue in a state that leaves Exim unable to deliver it. Exim does not assert that it has sent a \n before trying to end an SMTP DATA transmission with ., which some Exim devs are currently arguing over.

Related Topic