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

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.

Logged In: YES 
user_id=12800

Also moving to Feature Requests

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.

What about Python 2.6 support? :)

Is this still open for someone to work on?

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!

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

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

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.

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?

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.

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?

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.

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

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.

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.