[Python-Dev] Completing the email6 API changes.
v+python at g.nevcal.com
Mon Sep 2 07:55:58 CEST 2013
On 9/1/2013 8:03 PM, Stephen J. Turnbull wrote:
> This is getting off-topic IMO; we should probably take this thread to
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
> > 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
> 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:
> because the text/plain can't use the font. But this
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev