>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

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.



Reply via email to