Steve Holme wrote:

> Please note there are two bugs listed in this bug report:
> a) That curl doesn't handle LF to CRLF conversion
> b) That dot stuffing doesn't work

Yes, I know: I've read all comments :-) I started for a fix for b) but tests lead me to situations where a compliant server did not react properly if CURLOPT_CRLF was not set (I'm on Linux with LF endings). The default value for this option is FALSE, so it breaks the SMTP standard by default.

> I haven't been able to reproduce any other problems around b) now that the fixes for a) are present, but the user has, and for that reason I re-opened the bug report and await further feedback.

I've reproduced it: please find the mail data in attachment. Preserve the LF line ending for tests.
Use something like "curl --verbose -s -T smtp.data.txt --mail-rcpt <toCRaddr> --mail-from <fromaddr> smtp://<yourserver>", without the --crlf option. Watch the dialog with wireshark.
Note this will be the default behavior on Unix/Linux.
I've done the tests from a Linux 64-bit to a M$EXCH server 2003.

> However, I think that the topic of "whether non CRLF line ending conversion should be performed automatically by curl or not for certain protocols" whilst related to the bug report is a different conversation and one that I think should be explored here on the mailing list.

In fact, CURLOPT_CRLF unconditionally maps LF to CRLF (whether or not preceded by CR), while SMTP requires CRLF-->CRLF, LF->CRLF, CR-->CRLF.
We then can keep the option processing, but later apply the protocol standards for line (making the former almost useless for SMTP).
Results will be according to the following:

CURLOPT_CRLF Initial data SMTP-transmitted data
0 a<CR>b a<CRLF>b
0 a<LF>b a<CRLF>b
0 a<CRLF>b a<CRLF>b
0 a<LF><CR>b a<CRLF><CRLF>b
0 a<CR>.b a<CRLF>..b
0 a<LF>.b a<CRLF>..b
0 a<CRLF>.b a<CRLF>..b
1 a<CR>b a<CRLF>b
1 a<LF>b a<CRLF>b
1 a<CRLF>b a<CRLF><CRLF>b

The last case would be the only one affected by CURLOPT_CRLF: <CR><LF> --> <CR><CRLF> --> <CRLF><CRLF>.

>> Some objection ?
 
> My only objection is that we are then taking away the ability to allow the user to purposely send LF characters to the mail server for whatever reason
> - they may have a non RFC compliant mail server that requires the line ending to be LF or CR for example.

Well, I do not think a server that is so deviant will be able to receive normal e-mails properly... This is almost like changing a command syntax. Clever servers may extend the protocol by recognizing <CR> or <LF> alone as line ends, but even the most silly servers MUST support <CRLF>.

> However, whichever way we decide to go I do think that if mandatory auto conversion is to be performed then we should
> a) do the conversion for CR line endings as well,
> b) review which other protocols we should do this for
> c) not perform the conversion in SMTP specific code - this could be achieved by having a flag on the protocol handers that indicates the line ending type for example.

a) yes, I agree.
b) Why not, although the rules may be slightly different: SMTP data is always textual: if you want to have a finer control over the byte values and/or particular encodings, you must provide data in quoted-printable or base64. In fact, SMTP source data should be seen as printable ASCII [0x20-0x7E] records (whatever separates the records) and those records be transmitted with a trailing <CRLF>. Do we have other text-only based protocols ? Maybe IMAP and POP3, but these are mainly input protocols, so line-end mapping (if some) has to be performed the other way.
c) I don't think so: although this kind of conversion may be common, the protocol-dependent rules may be slightly different, as already said for b). This is really protocol specific.

@Dan: it does NOT take away the ability to send a message directly that already has CR/LF line endings, because <CRLF> --> <CRLF> when CURLOPT_CRLF=default.

Thanks for your comments.

Cheers,
Patrick

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html