This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author calimeroteknik
Recipients barry, calimeroteknik, r.david.murray
Date 2017-10-20.22:22:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1508538176.94.0.213398074469.issue31831@psf.upfronthosting.co.za>
In-reply-to
Content
The following code excerpt demonstrates a crash:

import email.message
mail = email.message.EmailMessage()
mail.add_attachment(
   b"test",
   maintype = "text",
   subtype  = "plain",
   filename = "I thought I could put a few words in the filename but apparently it does not go so well.txt" 
)
print(mail)

Output on python 3.7.0a1: https://gist.github.com/altendky/33c235e8a693235acd0551affee0a4f6
Output on python 3.6.2: https://oremilac.tk/paste/python-rfc2231-oops.log


Additionally, a behavioral issue is demonstrated by replacing in the above:
filename = "What happens if we try French in here? touché!.txt"


Which results in the following output (headers):

Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*=utf-8''What%20happens%20if%20we%20try%20French%20in%20here%3F%20touch%C3%A9%21.txt
MIME-Version: 1.0


Instead of, for example, this correct output (by Mozilla Thunderbird here):

Content-Type: text/plain; charset=UTF-8;
 name="=?UTF-8?Q?What_happens_if_we_try_French_in_here=3f_touch=c3=a9!.txt?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0*=utf-8''%57%68%61%74%20%68%61%70%70%65%6E%73%20%69%66%20%77%65;
 filename*1*=%20%74%72%79%20%46%72%65%6E%63%68%20%69%6E%20%68%65%72%65%3F;
 filename*2*=%20%74%6F%75%63%68%C3%A9%21%2E%74%78%74


Issues to note here:
-the "filename" parameter is not indented, mail clients ignore it
-the "filename" parameter is not split according to RFC 2231

The relevant standard is exemplified in section 4.1 of https://tools.ietf.org/html/rfc2231#page-5


Python 3.4.6 and 3.5.4 simply do not wrap anything, which works with  but is not conformant to standards.


Solving all of the above would imply correctly splitting any header.
Function "set_param" in /usr/lib/python*/email/message.py looked like a place to look.

Unfortunately I do not understand what's going on there very well.


As yet an additional misbehaviour to note, try to repeat the above print statement twice.
The result is not identical, and the second time you get the following output:

Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment;*=utf-8''What%20happens%20if%20we%20try%20French%20in%20here%3F%20touch%C3%A9%21.txt
MIME-Version: 1.0

It would appear that "filename" has disappeared.
The issue does not reveal itself with simple values for the 'filename' argument, e.g. "test.txt".


PS: The above output also illustrates this (way more minor) issue: https://bugs.python.org/issue25235
History
Date User Action Args
2017-10-20 22:22:57calimerotekniksetrecipients: + calimeroteknik, barry, r.david.murray
2017-10-20 22:22:56calimerotekniksetmessageid: <1508538176.94.0.213398074469.issue31831@psf.upfronthosting.co.za>
2017-10-20 22:22:56calimerotekniklinkissue31831 messages
2017-10-20 22:22:56calimeroteknikcreate