[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [nmh-workers] multipart/related and -prefer.
From: |
Ken Hornstein |
Subject: |
Re: [nmh-workers] multipart/related and -prefer. |
Date: |
Tue, 31 Jul 2018 22:40:45 -0400 |
>Typically, the text/plain and text/html are children of the same
>multipart/alternative, but here Apple thinks text/plain means images
>aren't required. Perhaps revenge for my never having purchased an Apple
>product.
Ralph, as far as I can tell ... nmh is doing exactly what you asked.
You told it, "Hey, if you run across a multipart/alternative, please
give me the text/plain version in preference to all others". And that's
exactly what happened.
And this isn't just an Apple problem; like Steffen said, this is common
in the Microsoft world as well (I see it all of the time when it comes
to calendar invites; I just see the text/plain version, but all of the
calendar stuff is part of multipart/mixed content). I think the use of
multipart/related is a red herring here.
This would require a lot of special-case code; you'd need to say, "Okay,
if if the other alternative type is a multipart/foo, AND the first type
of that is a text/html, then give me the text/plain part and then all of
the other parts after the text/html". That seems fragile, at least in
the core code. I think with my pie-in-the-sky "new MIME" architecture
you could write a helper script in the "part selector" phase that would
encompass that logic. But right now I think you're going to have to
engage your brain.
--Ken