Yeah, I was trying to wrap my head around how exactly Exim would be
accepting delivery, and it didn't even cross my mind to consider
Mailscanner modifying content when doing cleaning/disarming. Argh! Looks
like that's the cause for the \n missing, but the issue to me was never
really about the cause of the missing \n (although that's great to know,
and I'll hunt that down with the Mailscanner group soon), but about the
lack of assertion on Exim's side against that. I had opened a bug report
about this, but Nigel doesn't believe that Exim should be making sure
it's actually sending '.' on a new line in an SMTP transaction. It just
seems odd to me to rely solely on the content of a spool file for that
Phil Pennock wrote:
> On 2009-12-21 at 19:35 -0500, Brent Bloxam wrote:
>
>> 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 ;)
>>
>
> See, if we take that literally, that the only paht is the inbound
> daemon, then that means that the mail has to have come in via SMTP.
> Which means there *must* have been a CRLF.CRLF to end the mail (or NL.NL
> if client is not using CRLF) because otherwise the mail doesn't finish
> being accepted and so can't go into the spool.
>
> If you submit with { sendmail <recipient> } and finish the body with
> Ctrl-D Ctrl-D on a non-empty line, to get through a mail without a
> trailing newline, then Exim repairs it.
>
> Is Mailscanner doing any kind of "cleaning" of the content, or putting
> stuff directly into Exim's queue?
>
> -Phil
>
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
