Home / server / Questions / 96400
Accepted
brent
Asked: 2009-12-22 09:45:36 +0800 CST

Exim send failure "421 SMTP incoming data timeout" - Message body lacks '\n' at the end

  • 772

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 protected] 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.

email

2 Answers

  1. 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.

    • 1

  2. I think the spammers are doing this on purpose hoping that your mail server will backscatter the complete message (your SMTP server is following the rules so it will add the \n) to the innocent person listed on the Reply-to.

    To fix this, you need to get more aggressive with your anti-spam by checking that the senders IP is not listed in RBL lists, that the SPF record matches, etc.

    Another thought would be to flush your queue of these dead messages with a script every night. I don't know Exim well enough to suggest how to do this...

    HTH

    • 0