Brent Bloxam wrote:
> 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-->.
>
> Eventually the receiving MTA responds
>
>> 421 Lost incoming connection
>
> Passing the message in the spool through `od`, I see
>
>> 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,
>
>> /var/log/exim/eximout.log:2009-12-21 08:00:00 1NLolk-0003aD-3V == email@???
>> 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? "message_suffix" sounded like it would have
> been a good bandaid, but it only applies to appendfile and pipe.
>
Where are these problematic messages originating?
i.e.
- local. 'non-smtp' on-box process? (less common, on-box smtp process..)
- smtp incoming from a(n alleged) peer MTA? (you mentioned spam..)
- AUTH'ed user with (compromised) MUA?
2 and 3 can be stopped easily in an ACL.
The first needs a bit more work - but very much worth it.
Once you block their arrival, all the other problems (queue, delivery) go away.
Bill
