Possible standards violation: SMTPUTF8 and 8BITMIME

[pepoluan]

Was reading RFC 6531 and came upon Section 3.1 which explicitly states:

8. Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC6152].

Now if I initialize SMTP with enable_SMTPUTF8=True and decode_data=True, then the EHLO session returns:

b'220 MY-LAPTOP Python SMTP 1.2.3a2\r\n'
b'250-MY-LAPTOP\r\n'
b'250-SIZE 33554432\r\n'
b'250-SMTPUTF8\r\n'
b'250 HELP\r\n'

which is in violation of RFC 6531 § 3.1 number 8 above.

There's also a bit of complexity w.r.t. mail body itself (i.e., data following the DATA command); RFC 6531 § 3.6 specifies that

... The SMTPUTF8 extension MAY be used as follows (assuming it is appropriate given the body content):

• with the BODY=8BITMIME parameter [RFC6152], or

• with the BODY=BINARYMIME parameter, if the SMTP server advertises BINARYMIME [RFC3030].

This will require some rethinking on the logic behind enable_SMTPUTF8 and decode_data

[pepoluan]

This might have some interaction with #217

[pepoluan]

As with #217, fixing this will likely break things.

I'm deferring this to "2.0" milestone.