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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
