multipart
Today I received an email from someone who said they'd attached a file I needed, but I couldn't see the attachment. After some digging, I found that the message was structured like this:
multipart/alternative: (i.e. "these are alternative versions of the same thing")
-- text/plain (a version of the message in plain text)
-- multipart/related: (i.e. "these parts belong together")
-- -- text/html (a version of the message in HTML)
-- -- the attachment
So if your email program shows HTML for preference, you would see the attachment, but if it shows plain text for preference (as mine does), you wouldn't. Of course it *should* have been structured like this:
multipart/related: (i.e. "these parts belong together")
-- multipart/alternative: (i.e. "these are alternative versions of the same thing")
-- -- text/plain (a version of the message in plain text)
-- -- text/html (a version of the message in HTML)
-- the attachment
multipart/alternative: (i.e. "these are alternative versions of the same thing")
-- text/plain (a version of the message in plain text)
-- multipart/related: (i.e. "these parts belong together")
-- -- text/html (a version of the message in HTML)
-- -- the attachment
So if your email program shows HTML for preference, you would see the attachment, but if it shows plain text for preference (as mine does), you wouldn't. Of course it *should* have been structured like this:
multipart/related: (i.e. "these parts belong together")
-- multipart/alternative: (i.e. "these are alternative versions of the same thing")
-- -- text/plain (a version of the message in plain text)
-- -- text/html (a version of the message in HTML)
-- the attachment
no subject
no subject
That cured me of my gobsmacked disbelief – at least now the sending MUA only got the wrong one of two MIME structures with sensible purposes, rather than inventing something so weird it could not possibly have been useful for anything :-)
no subject