Author: W B Hacker Date: To: exim users Subject: Re: [exim] 421 SMTP incoming data timeout - Message body lacks '\n'
Brent Bloxam wrote: > Hi Phil,
>
> Phil Pennock wrote:
>> How sure are you that the point where you use tcpdump is not being
>> filtered by something like a protocol-level firewall messing up the
>> connection?
>>
> 100% sure, both servers are under my control, including all network
> points between them.
>> Can you use { exim -Mvb } to look at the message-body, or go look at the
>> raw file in the spool itself?
>>
> The output pushed through `od` was from both -Mvb and a direct cat of
> the message body in the outbound spool (output was identical). If I add
> a \n to the end of the body in the spool, Exim delivers it without issue
>> What are the paths for spam to get into the system? Is this a dedicated
>> mail-server, or the mail-server on a web-host used for sending mail from
>> forms, or what?
>>
> Dedicated mail server, only path is through the inbound queue-only Exim
> daemon. Spam is processed with Mailscanner, and while it's entirely
> possible the reason there's no newline on the spool file is because of
> it, I'm weary of that being the case as there's plenty of other spam
> making it through ;)
>
Like it or not, there - almost certainly - is your culprit. The sequence of
events with Mailscanner in the middle, though not necessarily Mailscanner itself.
- IF the incoming traffic had no proper termination YOUR Exim queue-only
front-end would have had the same problem as the far-end exhibits on the
outbound side - ultimately not taking it onboard.
That Exim accepts it indicates that whatever ELSE might be amiss, the message is
almost certainly correctly terminated at time of first arrival.
How, and at what point in the sequence of events, are you handing it off to
Mailscanner? And how is it being returned?
Test your relevant acl(s) and router/transport sets. And Mailscanner...
BTW - don't 'weary' about it. Create a test message with the flawed termination
and test it. Live or debug.
