New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart #46148
Comments
Steps to Reproduce >>> from email.mime.multipart import MIMEMultipart
>>> from email.mime.text import MIMEText
>>> multipart = MIMEMultipart()
>>> multipart.set_charset('UTF-8')
>>> text = MIMEText("sample text")
>>> multipart.attach(text)
>>> print multipart.as_string()
MIME-Version: 1.0
Content-Type: multipart/mixed; charset="utf-8";
boundary="===============0973828728=="
Content-Transfer-Encoding: base64 --===============0973828728== sample text
--===============0973828728==--
>>> multipart = MIMEMultipart()
>>> multipart.attach(text)
>>> multipart.set_charset('UTF-8')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
email/message.py", line 262, in set_charset
self._payload = charset.body_encode(self._payload)
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
email/charset.py", line 384, in body_encode
return email.base64mime.body_encode(s)
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
email/base64mime.py", line 148, in encode
enc = b2a_base64(s[i:i + max_unencoded])
TypeError: b2a_base64() argument 1 must be string or read-only buffer,
not list Explanation In the second example, I demonstrate that if you try and call Notes Again, this is something I'm willing to work on in next saturday's bug |
I'd like to question whether anything needs to be fixed at all, i.e. Barry, can you take a look? |
Martin, I can almost agree with you _if_ I was setting the Content-Transfer- Also, just from a usability point of view I would expect that creating |
Please provide an unit test which verifies the bug and a fix for the bug. |
You're right that this should probably be fixed in the subclass, but you |
I'm beginning to realise this is slightly bigger than I first thought Trying to make a nice test case for this issue, I thought it would be a |
Run out of time to look at this today. In order to write a nice test |
Okay, splitting this out a little. I've moved the exception when setting Here's a simpler example of the problem with setting character sets on >>> from email.MIMEMultipart import MIMEMultipart
>>> msg = MIMEMultipart()
>>> msg.set_charset('iso-8859-15')
>>> print msg.as_string()
MIME-Version: 1.0
Content-Type: multipart/mixed; charset="iso-8859-15";
boundary="===============1300027372=="
Content-Transfer-Encoding: quoted-printable As a programmer, I don't think I've done anything wrong, but that mail That said, when would you ever need or want to set the character set on |
As far as I can tell it is simply wrong per-RFC to put a charset parameter on a mulitpart content-type. So I think this should, indeed, raise an error on the Multipart subtype. If someone sets any charset, the CTE is set wrong. So code that sets charset is already broken, even though tolerant mailers will accept the resulting message (but some mailers won't, as described in this issue). So, I think set_charset on MIMEMultipart should be deprecated and turned into a no-op in 3.2. |
Fine with me to fix this API during beta. |
This issue is not newcomer friendly, I remove the easy keyword. |
This issue is still present on Python 3.7 and above. As David suggested set_charset could be turned into a no-op on MIMEMultipart. I traced set_charset back to inheritance from email.message.Message, would overriding set_charset (and possibly raising a deprecation warning) be an acceptable fix? |
I agree with @victor. I removed the easy tag on this easy |
Updating the Python versions to the only active ones on which this bug could conceivably be fixed. I haven't validated that it's still a problem, and I haven't decided whether it's appropriate to backport to 3.9 and 3.8. I'll work on a patch and see how it goes. |
The other question is what to do about |
Actually, I think I am going to close this as won't fix, for two reasons. First, this only potentially affects the legacy API, and second, in Python 3, the error you get when you do it like the original repro example seems obvious to me.
|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: