[Python-Dev] Completing the email6 API changes.

[Glenn Linderman]

On 9/1/2013 8:03 PM, Stephen J. Turnbull wrote:
> This is getting off-topic IMO; we should probably take this thread to
> email-sig.

Probably, but you didn't :)

> Glenn Linderman writes:
>
>   > I recall being surprised when first seeing messages generated by
>   > Apple Mail software, that are multipart/related, having a sequence
>   > of intermixed text/plain and image/jpeg parts. This is apparently
>   > how Apple Mail generates messages that have inline pictures,
>   > without resorting to use of HTML mail.
>
> (Are you sure you mean "text/plain" above?  I've not seen this form of
> message.  And you mention only "text/html" below.)

Yes, I'm sure it was text/plain. I may be able to access the archived 
discussion from a non-Python mailing list about it, to verify, if that 
becomes important.  But now that you mention mulitpart/mixed, I'm not 
sure if it was multipart/related or mulitpart/mixed for the grouping 
MIME part. Perhaps someone with Apple Mail could produce one... probably 
by composing a message as text/plain, and dragging in a picture or two.

The other references to text/html was in error.

> This practice (like my suggestion) is based on the conjecture that
> MUAs that implement multipart/related will treat it as multipart/mixed
> if the "main" subpart isn't known to implement links to external
> entities.
>
>   > Other email clients handle this relatively better or worse,
>   > depending on the expectations of their authors!
>
> Sure.  After all, this is a world in which some MUAs have a long
> history of happily executing virus executables.
>
>   > I did attempt to determine if it was non-standard usage: it is
>   > certainly non-common usage, but I found nothing in the email/MIME
>   > RFCs that precludes such usage.
>
> Clearly RFCs 2046 and 2387 envision a fallback to multipart/mixed, but
> are silent on how to do it for MUAs that implement multipart/related.
> RFC 2387 says:
>
>      MIME User Agents that do recognize Multipart/Related entities but
>      are unable to process the given type should give the user the
>      option of suppressing the entire Multipart/Related body part shall
>      be. [...]  Handling Multipart/Related differs [from handling of
>      existing composite subtypes] in that processing cannot be reduced
>      to handling the individual entities.
>
> I think that the sane policy is that when processing multipart/related
> internally, the MUA should treat the whole as multipart/mixed, unless
> it knows how links are implemented in the "start" part.  But the RFC
> doesn't say that.
>
>   > Several of them treat all the parts after the initial text/html
>   > part as attachments;
>
> They don't implement RFC 2387 (promoted to draft standard in 1998,
> following two others, the earlier being RFC 1872 from 1995).  Too bad
> for their users.

Correct... but the MUA receiving the Apple Mail message I was talking 
about being a text-mostly MUA, it is probably a reasonable method of 
handling them.

> But what I'm worried about is a different issue,
> which is how to ensure that multipart/alternative messages present all
> relevant content entities in both presentations.  For example, the
> following hypothetical structure is efficient:
>
>      multipart/alternative
>          text/plain
>          multipart/related
>              text/html
>              application/x-opentype-font
>
> because the text/plain can't use the font.  But this
>
>      multipart/alternative
>          text/plain
>          multipart/related
>              text/html
>              image/png
>              image/png
>
> often cost the text/plain receiver a view of the images, and I don't
> see any way to distinguish the two cases.  (The images might be
> character glyphs, for example, effectively a "poor man's font".)

Yes, that issue is handled by some text MUA by showing the image/png (or 
anything in such a position) as attachments. Again, being text-mostly, 
that might be a reasonable way of handling them. Perhaps the standard 
says they should be ignored, when displaying text/plain alternative.

> OTOH, if the message is structured
>
>      multipart/related
>          multipart/alternative
>              text/plain
>              text/html
>          image/png
>          image/png
>
> the receiver can infer that the images are related to both text/*
> parts and DTRT for each.
>
With the images being treated as attachments. Or is there a syntax to 
allow the text/html to embed the images and the text/plain to see them 
as attachments?  I think the text/html wants to refer to things within 
its containing multipart/related, but am not sure if that allows the 
intervening multipart/alternative.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130901/874f57b8/attachment.html>