They're inbound from the cloud to any of our hosted domains. I'm not
concerned with blocking the sender, more so with how they're getting
into the spool in the first place if there's no '\n's at the end of the
message body, and why the smtp transport driver will attempt to deliver
the message without correcting it (shouldn't that be considered a bug to
not assert \n before sending . for DATA?)
What I'm worried about is the potential of a non-spam source having this
issue, and those messages getting stuck in our spool
W B Hacker wrote:
> 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
>
--
| .-> brent bloxam ~-. brentb @ beanfield.com
| ( ) beanfield metroconnect
| `~- wgxolq +uajq <-' 416.532.1555 ext. 2004
--
