[Mailman-Users] Could Mailman cope with extra Mime sections intended for Apple Watches?

[Stephen J. Turnbull]

Mark Sapiro writes:
 > On 05/17/2015 04:04 PM, Peter Shute wrote:

 > > This isn't something that's happening right now, and I doubt it
 > > will, but you never know. Apple is playing with mail formats
 > > intended to display as a message summary on an Apple Watch, but
 > > show the full message on a larger device. Apparently it's a legal
 > > format,

The MIME is legal.  (More below.)  The HTML may be legal, but it's
deprecated (no DOCTYPE, no HTML element, etc).

However, it's a very stupid format.  Apple should just define and
register an Apple-Watch-Summary header field and put it there.

 > > but lots of mail clients are getting it wrong,

Too bad for them.  What they are supposed to do work down the list of
alternative types, and pick the last one they can handle.  Presumably
the Watch looks at the last text/html part, says to itself "Way too
big!" and backs up to the tiny text/html part.

 > > and I'm wondering what Mailman would do with a message like that.
 > 
 > Process it in conformance with the MIME RFCs and the list's content
 > filtering.

AFAIK, Mailman doesn't read any content in the body (except maybe in
spam filtering? but I think not even there), and filters only on MIME
Content-Type and filename extensions in "name" parameters.

 > I looked at that, and it appears the structure of the message is as follows
 > 
 > multipart/mixed
 >     multipart/alternative
 >         text/plain
 >             plain text version
 >         text/html
 >             html 'summary'
 >         text/html
 >             html version

Agree.

 > This is arguably non-conformant. multipart/alternative parts are
 > supposed to contain sub-parts which are alternative representations of
 > the message arranged in increasing order of complexity,

Agree, with s/arguably// (nobody in their right mind who isn't an
Apple Watch developer would argue this is conformant) and
s/complexity/faithfulness/ per RFC 2046.  Apple Watch fans might argue
for s/complexity/preference/ (another term used in RFC 2046), but the
interpretation that "whatever the author wants goes" is perverse in
the presence of the word "faithfulness".

 > and MUAs are supposed to render the most complex (supposedly
 > closest to the original) that they understand.

No, s/most complex/last/.  Apple is being perverted here: they're
relying on the letter of the law to "hide" the Watch summary from real
MIME-conformant MUAs, and then having the Watch implement a
non-conformant algorithm (there's nothing that says a conformant MUA
can select on anything but MIME type).

 > In short, Mailman will do the right thing, but Apple watch users
 > probably won't like the result in some cases.

Agreed.

 > <rant>
 > Apple is notorious for playing fast and loose with email. I don't know
 > if it's still the case, but at one point, Apple mail would let you drag
 > and drop pictures into a plain text email so it would look to Apple mail
 > users as
 > 
 > some text
 > [picture]
 > more text
 > [picture]
 > etc.
 > 
 > with a MIME structure like
 > 
 > multipart/mixed
 >     text/plain
 >     image/jpeg
 >     text/plain
 >     image/jpeg
 >     text/plain
 > 
 > and Apple mail would render what the sender saw and every other MUA
 > would see a text/plain message with 4 attachments.
 > </rant>

I've never had a problem with that structure, as long as
disposition=inline (which is default for text/* for most MUAs).  Even
on a TTY, all MIME-capable Emacs MUAs will display that as

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
    eiusmod tempor incididunt ut labore et dolore magna aliqua.

    [Save attachment][Display attachment using external program]

    Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
    nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in
    reprehenderit in voluptate velit esse cillum dolore eu fugiat
    nulla pariatur.

    [Save attachment][Display attachment using external program]

    Excepteur sint occaecat cupidatat non proident, sunt in culpa qui
    officia deserunt mollit anim id est laborum.

I know that there are GUI MUAs that can't handle it, but MIME did
envision that structure leading to an inline presentation of the
images (and audio or video or application/*, for that matter) if the
terminal is capable.

What pisses *me* off about Apple-generated email is their habit of
hiding attachments inside of text/html parts as <src cid="..."/>
elements.  (I consider my MUA to be broken because it doesn't display
them even when I ask for the full MIME structure, but it's annoying
that they aren't available when displaying the text/plain MIME part.)
AFAICT, instead of

multipart/alternative
    text/plain
    multipart/mixed
        text/html        # containing CID references
        image/jpeg       # with CID

what should work fine is

multipart/mixed
    multipart/alternative
        text/plain
        text/html        # containing CID references
    image/jpeg           # with CID

or something like that.