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
Subject: SMTP example message .The body of the message starts here. . It could be a lot of lines, could be MIME encoded, whatever. Check RFC5322.
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
