RFC 2387 (multipart/related) in email package

[warsaw]

BPO	634412
Nosy	@warsaw, @tiran, @devdanzin, @bitdancer, @vadmium

^{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-feature', 'expert-email'] title = 'RFC 2387 (multipart/related) in email package' updated_at = user = 'https://github.com/warsaw' ``` bugs.python.org fields: ```python activity = actor = 'martin.panter' assignee = 'none' closed = False closed_date = None closer = None components = ['email'] creation = creator = 'barry' dependencies = [] files = [] hgrepos = [] issue_num = 634412 keywords = [] message_count = 17.0 messages = ['53674', '53675', '53676', '53677', '59361', '157498', '157508', '169105', '218645', '218663', '219562', '219583', '219791', '219820', '220138', '220309', '220329'] nosy_count = 8.0 nosy_names = ['barry', 'christian.heimes', 'ajaksu2', 'etiffany', 'r.david.murray', 'martin.panter', 'moijes12', 'abhilash.raj'] pr_nums = [] priority = 'low' resolution = None stage = 'needs patch' status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue634412' versions = ['Python 3.5'] ```

[warsaw]

Figure out if and how to support multipart/related as specified in RFC 2112, in the email package.

[warsaw]

Logged In: YES user_id=12800

Moving this to Python 2.4. The email-sig should address this for email 3.0/Python 2.4.

[warsaw]

Logged In: YES user_id=12800

Also moving to Feature Requests

[b63f2f68-f2b9-48e1-a184-86ebb6ebad7a]

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.

[tiran]

What about Python 2.6 support? :)

[f6b1112c-a710-4ed6-bc6a-95202e665ef8]

Is this still open for someone to work on?

[bitdancer]

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!

[bitdancer]

http://tools.ietf.org/html/rfc2387 has obsoleted 2112.

[5d4e6c0e-6688-4d45-92fb-ed8fb7a3645b]

I would like to work on this issue, but I would need a little help to start working on this feature.

[bitdancer]

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.

[5d4e6c0e-6688-4d45-92fb-ed8fb7a3645b]

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?

[bitdancer]

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.

[5d4e6c0e-6688-4d45-92fb-ed8fb7a3645b]

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?

[bitdancer]

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

https://docs.python.org/3/library/email-examples.html#examples-using-the-provisional-api

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.

[5d4e6c0e-6688-4d45-92fb-ed8fb7a3645b]

David: How does this API look? https://gist.github.com/maxking/2f37bae7875dde027e3c

[bitdancer]

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.

[5d4e6c0e-6688-4d45-92fb-ed8fb7a3645b]

David: What about his API then? https://gist.github.com/maxking/b3ed4f54674e5f480275

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.

[YaverJavid]

SO THIS WAS THE FIRST; Cool

[zitterbewegung]

I believe this should be closed. We have the following package below that was put in 3.6 that would solve this problem.

https://docs.python.org/3/library/email.contentmanager.html#module-email.contentmanager

@iritkatriel do you believe this api should exist?

[iritkatriel]

@iritkatriel do you believe this api should exist?

I don't know. @warsaw and @bitdancer might.

[bitdancer]

If I recall correctly, we decided that since the contextmanager is pluggable via the policy object, we'd let people develop extension packages and decide later if there was something more we wanted to pull in/add to the email library. I haven't looked around to see if anyone has taken up that gauntlet ;)

[warsaw]

Me neither, but since I opened this ticket 22 years ago and it's still open, I say we close this and let someone else take up that gauntlet if and when the it makes sense.