Blank messages because multipart/alternative message contains multipart/alternative part

I'll try to test this out, but would appreciate any other input if anyone else has looked at this and tried this with other mail clients.

I've seen what you're referring to now in my testing, and will see what I can do to fix it. Incidentally this will also (mostly) fix the plain text portion not being selectable in some mail agents.

The problem does go deeper than just what is mentioned here, but even with some fixes it's not clear whether or not all mail agents will respect the formatting, even when it conforms more closely to the RFC.

I'm wondering if there's been any progress on this issue? We've had a couple of customers contact us who are running Eudora on Windows. They are telling us they are receiving their newsletters as a blank page. If I attempt to review one of the Simplenews newsletters in Thunderbird with HTML rendering it looks fine. If I select "plain text only" in Thunderbird, it is blank.

I have tested this solution and it fixes the problem for email clients such as Thunderbird, but it does not work for Outlook 2007/Hotmail.

In Outlook 2007/Hotmail, the entire email is blank, both plain text and HTML. The email is blank even though I have applied the Outlook 2003/2007 patch (http://drupal.org/node/225731). Adding the $content_type line above causes a blank email just like if the Outlook 2003/07 patch had not been applied at all.

Just wanted to point out that I've also received word from a few contact that an announcement email sent with simplenews and mimemail arrived blank

Any definitive answer on who this might affect. I am sending to mostly school board emails, and since clients tend to be standardized, it might help me decide whether I should look into alternatives. I'm a little worried that not even the sender would show up, in which case they might simply erase it without knowing where it came from.

Thanks to anyone who can offer advice! :)

We have just had similar problems with clients using Hotmail and Entourage. I worked around this by editing mimemail.inc to add a conditional return value that doesn't wrap the content that extra, unnecessary time at all:

if (!$mime_parts && !$attachments) return $content;
return mimemail_multipart_body($parts, "$content_type; charset=utf-8");

This one-line fix works correctly for e.g. SquirrelMail (webmail client), and also works correctly of course in clients like Evolution.
N.B. I'm using Drupal 6, but the results are the same.
Attached steve.m's one-line fix as a patch so other people don't have to look for the correct line in the code. ;-)

This approach works for me also. Previously emails were coming through to the iPhone in text format, but after applying this, they're in HTML format.

Closing issue, Drupal 5 is no longer officially supported.