Two bugs fixed! The first was trivial, adding one line of code for a case I had overlooked initially. The second was more subtle. I eventually tracked down the cause to a less common variant in the MIME headers.
Here’s a typical MIME header:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
And here’s the header I was seeing in the error producing email:
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Content-Type: text/html
Notice anything majorly different? Take a look at that content-type. In the second-example, it didn’t specify the charset, so there’s no semicolon after the content type string. And that meant that some existing code that parsed out the content-type would fail if the charset was missing. Position of semi-colon returning zero (not found) when you want it to return end of string if not found…slight difference, now it gets the full content-type in the latter case instead of a blank string and displays correctly.