Re: [exim] 421 SMTP incoming data timeout - Message body lac…

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Jethro R Binks
Dátum:  
Címzett: exim-users
Tárgy: Re: [exim] 421 SMTP incoming data timeout - Message body lacks '\n'
On Tue, 22 Dec 2009, Brent Bloxam wrote:

> 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


I've not really been paying attention to this thread, but now someone's
mentioned MailScanner, my ears perked up.

I have a persistent problem with mails from, in particular, topica:

 5d  7.5K 1NLHVf-000Kpe-9Y <lotsofcrapg@???>
          recipient@???


These get stuck on the "out" queue of my MX, as the next hop is an
Exchange server and Exim times out trying to pass them on to it. This is
because these messages do not end in "\n" (visible with exim -Mvb msgid |
cat -e). For some time I have suspected that MailScanner is at fault, but
never really had the wherewithall to get enough information to make a
decent report for Julian. It is curious that it predominantly happens for
messages from particular senders (like topica) rather than randomly, which
suggests perhaps some condition or fault on the inbound message, but there
you go.

I did post about it some time ago:

http://lists.exim.org/lurker/message/20081003.110247.ada9331e.en.html

Jethro.


>
> 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/
>


. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks
Computing Officer, IT Services, University Of Strathclyde, Glasgow, UK