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.

Title: RFC 2387 (multipart/related) in email package
Type: enhancement Stage: needs patch
Components: email Versions: Python 3.5
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: abhilash.raj, ajaksu2, barry, christian.heimes, etiffany, martin.panter, moijes12, r.david.murray
Priority: low Keywords:

Created on 2002-11-06 13:14 by barry, last changed 2022-04-10 16:05 by admin.

Messages (17)
msg53674 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2002-11-06 13:14
Figure out if and how to support multipart/related as
specified in RFC 2112, in the email package.
msg53675 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2003-11-21 20:23
Logged In: YES 

Moving this to Python 2.4.  The email-sig should address
this for email 3.0/Python 2.4.
msg53676 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2003-11-21 20:24
Logged In: YES 

Also moving to Feature Requests
msg53677 - (view) Author: Eric Tiffany (etiffany) Date: 2007-05-15 13:37
What is the status of this item?  I don't seem to find support for mulitpart/related in the email library in python 2.4.
msg59361 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-06 12:42
What about Python 2.6 support? :)
msg157498 - (view) Author: moijes12 (moijes12) Date: 2012-04-04 19:30
Is this still open for someone to work on?
msg157508 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-04-04 21:10
Yes, that's why its status is still "open" :)

As far as I know no one is actively working on it (email issues are all assigned to me so I can keep track of them, not because I'm actively working on all of them).

At this point I haven't made any significant modifications to the way mime parts are handled in email6, so any development work you do should be valid whether you work against 3.3 trunk or the email6 feature branch.  Joining the email-sig mailing list and discussing this there might also be helpful.

Thank you for your interest!
msg169105 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-08-25 01:21 has obsoleted 2112.
msg218645 - (view) Author: Abhilash Raj (abhilash.raj) * Date: 2014-05-16 07:25
I would like to work on this issue, but I would need a little help to start working on this feature.
msg218663 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-05-16 14:40
There is some support for this in the new email policies.  Take a look at the new examples in the 3.4 email documentation in particular.

The additional thing I would like to see is support in the content manager that recognizes multipart/related and makes it easy to manage one.  I have to find time to look at it again myself before I can provide my ideas of what the API should be.  Maybe you could take a look at the docs and examples and how the contentmanager works, and see if you have thoughts or questions.
msg219562 - (view) Author: Abhilash Raj (abhilash.raj) * Date: 2014-06-02 09:42
David: I had a look at the examples and documentation as you said. I found some support for multipart/related in the form of  `add_related` and `set_related` methods. But I am still confused on how to make content_manager recognize miltipart/related messages. Do I need to add a new content-manager instance like `raw_content_manager` or something else?
msg219583 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-06-02 13:13
My idea (which I haven't worked out in detail) is to add either a new content manager that extends raw_data_manager, or just add to raw_data_manager, a handler for 'multipart/related'.  The set handler would handle a value of type 'dict', and expect it to contain a mapping from content-ids to...something.  What the 'something' is is the part I'm not clear on yet.  Trivially it could be MIMEParts, but that may not be the most convenient API.  Or perhaps it *should* be MIMEParts, with a helper utility to make building the dict easy.  The 'get' handler would return a dict in the same format, whatever we decide that format should be.
msg219791 - (view) Author: Abhilash Raj (abhilash.raj) * Date: 2014-06-05 10:14
Will the building of that 'dict' really be that difficult? Can we not walk over all the attachments and simply map cid to name of the attachment? All attachments have to have different names if I am right?
msg219820 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-06-05 15:30
No, there is no requirement that attachment names be unique, and in fact no requirement that attachments (inline attachments, which is mostly what we are dealing with for 'related') have names at all.  I have seen messages in the wild that had more than one attachment with the same name, and it revealed a bug in the system I was working on at the time :)

Building the dictionary is not *hard*.  I am not satisfied with the code shown in

I think there should be a more elegant way to spell the multipart/related creation parts of that example.  Feeding a dictionary in as the entire 'related' part would be better, but in order to create that dictionary you have to explicitly create MIMEPart subparts and store them in the dict.  That may be what we end up doing, but I think it would be nice if there was a more intuitive way to spell it.  

Especially since as it stands you have to explicitly munge the CIDs.  You shouldn't have to do that, the library should take care of that for you.
msg220138 - (view) Author: Abhilash Raj (abhilash.raj) * Date: 2014-06-10 06:27
David: How does this API look?
msg220309 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-06-11 20:56
It is a clever idea, and might be worth considering, but it doesn't feel natural to have to specify the attachments before the html.  What I'd really like is an API that hides the messy details of the RFC from the library user, and I haven't thought of anything I'm satisfied with yet.  Specifically, it would be great if the 'keys' could be specially formatted strings ("@mypicid1@" or something like that) and the helper would automatically replace them with cids in both the html and the attachments.

It would probably be worth taking this discussion to the email-sig mailing list.
msg220329 - (view) Author: Abhilash Raj (abhilash.raj) * Date: 2014-06-12 03:01
David: What about his API then?

Here cids are generated behind the scenes when the html part is added and those  cids are assigned to the attachments on the first come basis?
Like {0} is replaced by the cid of `roasted-asparagus.jpg`, I think you get the idea?

I will post a brief summary of this discussion to email-sig list later today.
Date User Action Args
2022-04-10 16:05:49adminsetgithub: 37428
2014-12-17 02:15:20martin.pantersettitle: RFC 2387 in email package -> RFC 2387 (multipart/related) in email package
2014-06-12 03:01:26abhilash.rajsetmessages: + msg220329
2014-06-11 20:56:24r.david.murraysetmessages: + msg220309
2014-06-10 06:27:13abhilash.rajsetmessages: + msg220138
2014-06-06 07:07:10martin.pantersetnosy: + martin.panter
2014-06-05 15:30:30r.david.murraysetmessages: + msg219820
2014-06-05 10:14:41abhilash.rajsetmessages: + msg219791
2014-06-02 13:13:36r.david.murraysetmessages: + msg219583
2014-06-02 09:42:12abhilash.rajsetmessages: + msg219562
2014-05-16 14:40:49r.david.murraysetversions: + Python 3.5, - Python 3.4
2014-05-16 14:40:35r.david.murraysetmessages: + msg218663
2014-05-16 07:25:36abhilash.rajsetnosy: + abhilash.raj
messages: + msg218645
2013-11-06 19:28:59akuchlingsetkeywords: - easy
2012-08-25 01:21:05r.david.murraysettitle: RFC 2112 in email package -> RFC 2387 in email package
messages: + msg169105
versions: + Python 3.4, - Python 3.3
2012-05-24 14:52:43r.david.murraysetassignee: r.david.murray ->
components: + email, - Library (Lib)
stage: test needed -> needs patch
2012-04-04 21:10:56r.david.murraysetmessages: + msg157508
components: + Library (Lib), - Interpreter Core
2012-04-04 19:30:14moijes12setnosy: + moijes12
messages: + msg157498
2010-12-27 18:20:54r.david.murraysetnosy: barry, christian.heimes, ajaksu2, etiffany, r.david.murray
versions: + Python 3.3, - Python 3.2
2010-08-09 04:40:15terry.reedysetversions: + Python 3.2, - Python 3.1, Python 2.7
2010-05-05 13:53:14barrysetassignee: barry -> r.david.murray

nosy: + r.david.murray
2009-04-22 17:21:20ajaksu2setkeywords: + easy
2009-02-13 02:17:39ajaksu2setnosy: + ajaksu2
stage: test needed
versions: + Python 3.1, Python 2.7, - Python 2.6
2008-01-06 12:42:38christian.heimessetassignee: barry
messages: + msg59361
nosy: + christian.heimes
components: + Interpreter Core, - None
versions: + Python 2.6
2002-11-06 13:14:41barrycreate