On Fri, 24 Mar 2017 16:09:36 +0100 (CET) Daniel Stenberg <[email protected]> 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
