On Thu, 17 Jul 2003, Barry Pederson wrote:
> I was trying to use Exim with Cyrus IMAP 2.1.14, and found that messages
> generated by Cyrus' sieve filters, for vacations, forwards, and such - were
> getting mangled by Exim 4.20. Exim adds an extra blank line after the first
> header line - which makes the rest of the headers end up being part of the
> message body.
There is a known issue in the way Cyrus and Exim treat line endings.
> You can reproduce this, without having to have Cyrus-IMAP, but making a
> simple file, named "test.msg" for example, that has CRLF line endings - such as:
Exim lives in a Unix world. In the Unix world, line ends are represented
by LF characters alone. If you pass a local file to Exim, it expects it
to use the convention of the local operating system, namely, to have LF
line endings. If you create a file with CRLF line endings, you are
breaking the conventions of the world. Exim will treat the CRs as data
characters. (You can use -dropcr to tell it to drop CRs, however.)
> Send it to yourself using Exim with something like:
>
> exim -i -f "<>" -- my@??? <test.msg
>
> and you'll see the extra blank line after "x-foo: bar", and the remaining
> headers now treated as body.
That should not be the case unless you deliver to Cyrus. Indeed, I have
just tested it using an appendfile delivery, and it is not the case.
Cyrus delivery has to be configured to use CRLF line endings, so what
Cyrus gets sent has lines ending in CRCRLF and it treats this as *two*
line ends. Hence the effect you see.
> This doesn't happen if the file has plain unix-style LF endings,
On a Unix system, one might hope that files *would* have Unix-style line
endings... Or am I being hopelessly naive?
> I wonder if this has to do with the bit mentioned in the docs for the "-bm"
> option where messages may, for compatibility with Sendmail and Smail, have
> things like:
>
>
> From sender Fri Jan 5 12:55 GMT 1997
> From sender Fri, 5 Jan 97 12:55:01
>
> as their first line. Could it be processing that first line specially, and
> mishandling the "\r\n" at the end.
No, that's not relevant.
The world is in a mess as regards line endings. It is hard to know what
should be done.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
