On Fri, 24 Mar 2017 16:09:36 +0100 (CET)
Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Thu, 16 Mar 2017, Deweloper wrote:
>
> > What do you think about adding support for 8BITMIME extension to
> > curl's SMTP client, as defined in
> > https://tools.ietf.org/html/rfc6152 ?
>
> I think it would fit!
>
> > Probably there should be a way to tell curl that the content we're
> > going to sent actually needs the 8th bit to be preserved. In such
> > case curl should fail when 8BITMIME capability is not supported by
> > the server. A new URL option, maybe?
>
> I figure libcurl shouldn't use this option unless specifically asked,
> right? And if asked, I suppose there would be a reason to ask for it
> and then we should probably fail the transfer if the requirement
> can't be met.
>
> Or am I missing something?
>

That's right.
Theoretically, the option could be used anyway because content valid
for 7bit encoding is valid for 8bit encoding as well.
However, if server-side implementation of 8BITMIME is buggy, using it
implicitly may create issues for applications which don't need it.
Also, application needs to make sure that it is allowed to supply 8bit
content to libcurl (probably TODO#7.2 will cover that).

On the other hand, the 8BITMIME extension still doesn't allow passing
arbitrary binary data. It must still be text-like (lines no longer than
1000 chars). So while it should make it possible to send e.g. UTF-8
text-only messages without base64/quoted-printable encoding,
applications sending binary content will still need to use such means.

There is RFC 3030 which defines BINARYMIME extension, what would be
much more beneficial, but it's still a draft, and no public SMTP server
I know supports it.

So it seems that there will be much lower profit of adding support for
8BITMIME to libcurl than I initially tought.

-- 
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html