R. David Murray added the comment:

Hmm.  Perhaps it would be better to close that one as a duplicate of this one, 
since this one doesn't start out as an error report that then got converted 
into an enhancement request...

The patch on that issue doesn't have anything to do with what the issue turned 
into, which is indeed a bit confusing.

I haven't given much thought to *how* to implement this support.  Depending on 
utf8smtp capability being present seems the best course.  If support isn't 
available, then the library should continue to raise an error, as it does now, 
but indeed the message could be improved.

In real life, of course, we want our message to get delivered regardless of 
whether or not smtputf8 is available.  To make that work, it will be advisable 
for the application to use the send_message interface rather than the sendmail 
interface: pass in a Message object, which can be automatically serialized as 
utf8 if smtputf8 is available, and the normal CTE encoding dances if not.  This 
of course will require support from the email package, specifically a 'utf8 
only' serialization mode.

If one is using smtplib only, then the application is responsible both for 
checking for the smtputf8 capability and branching accordingly, and for getting 
all the data correct...when I said "string only" I was referring to the methods 
in question (RCPT, etc).  DATA is a different story, and that has to handle 
both ascii-only strings or properly encoded (per the email RFCs) binary.  
Automatic encoding of non-ascii string DATA is dangerous, and would only work 
if the input is correctly formatted for the utf8 charset throughout.  
Personally I'd rather use the email package to ensure that...so if an 
application wants to bypass the email package, I think requiring it to manually 
encode the DATA string into utf8 is an acceptable interface requirement, to 
make it *clear* that there is no way to automatically encode an arbitrary email 
message (other than by using the email package).

These are just preliminary thoughts...there is probably more design work to be 
done before this can be implemented.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20084>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to