[imp] Bugs or configuration errors? (RFC 822 linebreaks.

[Chris Hastie]

On Fri, 5 Jul 2002, Michael M Slusarz <slusarz@bigworm.colorado.edu>
wrote
>Quoting Chris Hastie <lists@oak-wood.co.uk>:
>
>| Delivering by piping to the MTA IMP is sending only LF, or possibly only
>| what is native on that system, so LF on *nix and CRLF on Windoze. The
>| behaviour of different MTAs appears to differ here, and I'm guessing
>| Postfix is passing this unaltered, whilst Sendmail converts to CRLF
>| before placing in the SMTP stream. If I'm right about that it suggests
>| that somehow changing IMP's behaviour to send CRLF would work with
>| Postfix, which would pass them unaltered, and with Sendmail since the
>| thread you mentioned seems to suggest that's fine, but would break
>| Qmail, which it seems expects native LF, and converts them to CRLF. On
>| receiving a CRLF it converts the LF leaving CRCRLF.
>
>If I am reading this correctly, and piecing together what I know, we should
>send simple <LF> breaks and the MTA will figure this out and add the
>correct line breaks.  The problem comes with Windows - I'm assuming that
>Windows MTA's will correctly take IMP's input (with <LF> only) and will
>convert this to <CR><LF> - simply beacuse I have never heard of a Windows
>problem sending mail.  Then again, how many people are running IMP on
>windows?
>
>Thus, my conclusions:
>If sending via SMTP: <LF> are fine (<CR><LF> handled by Mail_smtp).
>If sending via MTA:  <LF> are fine (<CR><LF> handled by MTA).
>
>This is essentially (with the exception of base64 encoding in HEAD, which I
>will change in a few minutes) what IMP is already doing.
>Comments/questions on this?

Hi Michael

I've found time to try a few tests of Postfix and Imp and this is what
I've come up with.

Firstly I tried crafting two almost identical messages with a Base64
attachment, one with LF endings throughout and one with CRLF endings
throughout. I then piped each file to my sendmail wrapper. Both messages
arrived fine and where read perfectly by Turnpike, that MUA that
complains at IMP generated Base64.

This wasn't what I'd expected - I thought one of the two, probably the
LF only version, would confuse it.

So I then wrote a perl script to specify as my sendmail_path for Horde,
which grabbed the output and processed it to make CRLF and LF nice and
obvious. This is the result:

Starting test with arguments '-fxxxx@xxxx.xxx -- yyyy@yyyyyy.yyy'
Received: from 192.168.37.3 ( [192.168.37.3])<LF>
        as user xxxxx@zzzzzzzzzzzz by mail with HTTP;<LF>
        Mon,  8 Jul 2002 12:18:12 +0100<LF>
Message-ID: <1026127092.3d2974f4e5c40@mail><LF>
Date: Mon,  8 Jul 2002 12:18:12 +0100<LF>
From: Chris Hastie <xxxx@xxxx.xxx><LF>
To: yyyy@yyyyyy.yyy<LF>
Subject: Test to catch IMP output<LF>
MIME-Version: 1.0<LF>
Content-Type: multipart/mixed; boundary="-MOQ1026127092f087128486aed45b203a46502e8edcfe"<LF>
User-Agent: Internet Messaging Program (IMP) 3.1<LF>
X-Originating-IP: 192.168.37.3<LF>
<LF>
This message is in MIME format.<LF>
<LF>
---MOQ1026127092f087128486aed45b203a46502e8edcfe<LF>
Content-Type: text/plain<LF>
Content-Transfer-Encoding: 7bit<LF>
<LF>
This is a test.<LF>
With attachment.<LF>
<LF>
-- <LF>
Chris Hastie<LF>
---MOQ1026127092f087128486aed45b203a46502e8edcfe<LF>
Content-Type: image/pjpeg; name="JW_D_2a.jpg"<LF>
Content-Transfer-Encoding: base64<LF>
Content-Disposition: attachment; filename="JW_D_2a.jpg"<LF>
<LF>
/9j/4AAQSkZJRgABAQEASABIAAD/2wBDABALDA4MChAODQ4SERATGCcZGBYWGDAiJBwnOTI8Ozgy<CRLF>
NzY/R1pMP0NVRDY3TmtPVV1gZWZlPUtvd25idlpjZWH/2wBDARESEhgVGC4ZGS5hQTdBYWFhYWFh<CRLF>
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWH/wAARCAEUAaMDASIA<CRLF>
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA<CRLF>
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3<CRLF>
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm<CRLF>
...

So Imp is sending <LF> only after the header and text body lines, but
the lines making up the Base64 attachment are being sent with <CRLF>
endings. Postfix seems able to deal with one or the other, but not both
in the same message.

-- 
Chris Hastie