python / cpython

The Python programming language
https://www.python.org
Other
62.46k stars 29.98k forks source link

email MIME-Version headers for each part in multipart message #55230

Open bb72d266-46d0-421b-b28a-dad9f384268f opened 13 years ago

bb72d266-46d0-421b-b28a-dad9f384268f commented 13 years ago
BPO 11021
Nosy @warsaw, @bitdancer, @eriker-fsc

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: ```python assignee = None closed_at = None created_at = labels = ['type-bug', 'expert-email'] title = 'email MIME-Version headers for each part in multipart message' updated_at = user = 'https://bugs.python.org/davidcaro' ``` bugs.python.org fields: ```python activity = actor = 'eriker' assignee = 'none' closed = False closed_date = None closer = None components = ['email'] creation = creator = 'david.caro' dependencies = [] files = [] hgrepos = [] issue_num = 11021 keywords = [] message_count = 6.0 messages = ['127161', '127163', '130787', '130884', '130903', '384937'] nosy_count = 4.0 nosy_names = ['barry', 'r.david.murray', 'david.caro', 'eriker'] pr_nums = [] priority = 'normal' resolution = None stage = 'needs patch' status = 'open' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue11021' versions = ['Python 3.3'] ```

bb72d266-46d0-421b-b28a-dad9f384268f commented 13 years ago

When attaching a subpart to a multipart message, python should follow the recomendations of the rfcs and remove the MIME-Version header of each part, leaving only one MIME-Version header at the beggining of the message.

>>> from email.mime.multipart import MIMEMultipart
>>> from email.mime.text import MIMEText
>>> usermail=MIMEMultipart('alternative')
>>> part=MIMEText('text')
>>> print part
From nobody Thu Jan 27 00:33:50 2011
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

text
>>> usermail.attach(part)
>>> print usermail
From nobody Thu Jan 27 00:45:26 2011
Content-Type: multipart/alternative; boundary="===============1006894803=="
MIME-Version: 1.0

--===============1006894803== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit

text --===============1006894803==--

bitdancer commented 13 years ago

For the record, can you point to the relevant part of the relevant RFC?

bitdancer commented 13 years ago

Assuming this is correct (I haven't tried looking for the reference yet), I'm leaning toward it being enough of a behavior change that it should not be backported.

bb72d266-46d0-421b-b28a-dad9f384268f commented 13 years ago

Of course, the RFC that discusses the MIME-Version Header is RFC-2045 http://www.ietf.org/rfc/rfc2045.txt

Extract of the page 8: "Note that the MIME-Version header field is required at the top level of a message. It is not required for each body part of a multipart entity."

Strictly all the implementations should support the MIME-Version on each field, because the RFC does not explicitly say that it should not be included, but all the best practice documents that mention it say that it should not be included in all the parts, my main concern is that maybe it raises the spam level of the sent e-mails.

Maybe it's not critical enough to be backported, but at least, it should be changed for future versions.

Thanks

bitdancer commented 13 years ago

Yes, if it is not actually an RFC non-compliance I'd rather not backport it, but I'm not averse to changing it. I'm open to argument about backporting though...if you know of spam filters that actually do count it, let me know.

f03fd216-1ef4-4020-9d5c-703aa88fe301 commented 3 years ago

Propose to close as duplicate of https://bugs.python.org/issue25235