On Fri, 12 Dec 2014, Patrick Monnerat wrote:

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

True - and I believe this isn't quite correct and I may be wrong here but I
don't think the current option has been extended as it isn't used that much.

For example: Shouldn't we be performing CR to CRLF for input files that may
have come from some legacy systems?

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

Me neither - but, rightly or wrongly, we have had that functionality in curl
for the last 20+ releases and a mandatory conversion takes that away. I'm
not saying we should or shouldn't do that, I was just trying to highlight
why we might not want to make it mandatory and let others join in on the
discussion.

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

Indeed - I am very familiar with how data should be presented to an SMTP
server and interpreted from a POP3 server. The reason I ended up
contributing and then maintaining the email protocols in curl is I wrote all
of my employer's email functionality where we support both quoted printable
and base64 encoding/decoding for attachments, inline images and characters
outside the ASCII character set ;-)

> (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.

POP3 is definitely an input protocol but IMAP is bi-directional and is used
for sending emails where this translation could also be performed.

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

I disagree. Given that we a) already have the --crlf conversion being
performed in transfer.c and b) what you're suggesting could be used in other
protocols (such as IMAP) and I think this can and should be performed at the
transfer level if we decide to move ahead with it.

As I mentioned in my previous email we can implement a protocol specific
handler option to make it protocol specific but if you implement it in
smtp.c then someone else, maybe yourself, maybe myself is going to implement
something very similar in imap.c and any other protocols that want or need
this functionality in the future.

Kind Regards

Steve
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-12-14