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

[Michael M Slusarz]

Quoting Chris Hastie <lists@oak-wood.co.uk>:

| Using SMTP delivery IMP is sending CRLF throughout. What seems fairly 
| clear is that in an SMTP context this is what is expected by pretty much 
| everything.

This is correct.  The Mail_smtp class does all the necessary conversions 
from local format to <CR><LF> format.  Thus, we should be able to send in 
an entire message with line breaks of <LF> only and SMTP will work fine.  
This is what we currently do, and SMTP works, so that is good.  There is no 
need for us (as in IMP) to terminate with <CR><LF> since this is already 
taken care of.

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

michael

______________________________________________
Michael Slusarz [slusarz@bigworm.colorado.edu]
The University of Colorado at Boulder