Reply Bodies as Attachments
I'm having the same problem on all of my lists, which most people read on their Android or IOS devices.
When I send something out, if anyone replies, it is delivered with my defined header and footer, but the body is an attachment which can't be read. It says, "No Application Available for This Content".
I've looked through all of the settings and can't find anything related to it or that affects it.
Rex Goode
rex@rexgoode.com writes:
I'm having the same problem on all of my lists, which most people read on their Android or IOS devices.
When I send something out, if anyone replies, it is delivered with my defined header and footer, but the body is an attachment which can't be read. It says, "No Application Available for This Content".
I've looked through all of the settings and can't find anything related to it or that affects it.
The problem is almost surely that headers and footers added by Mailman using MIME conventions are more or less incompatible with HTML mail. Competent MUAs deal with this fine[1], but unfortunately competent MUAs are mostly found on Unix systems, not on the popular OSes or handheld devices.
There are workarounds for this that rewrite the HTML instead of using MIME, but we are unwilling to support them because rewriting HTML reliably across all of the variations put out by different MUAs requires a huge amount of effort, and won't be successful in the end because new variations arise daily -- it's whack-a-mole with no prizes.
There are three workarounds that usually help (you only need one). Which is best depends on your users' preferences and list practices. (1) Don't allow HTML mail. (2) Have Mailman convert it to text. (3) Don't add headers or footer at all. This means you have to delete everything, including whitespace, from those text boxes in the admin interface.
Footnotes: [1] The algorithm is easy to describe and shouldn't be hard to implement: print the plain text header using default formatting in a frame, print the mail itself in another frame, and then the footer in a third frame, stacking the frames vertically. This might be a strategy that would work in general, but last I checked you couldn't count on MUAs to support frames, so....
On 10/30/2016 09:50 AM, rex@rexgoode.com wrote:
I'm having the same problem on all of my lists, which most people read on their Android or IOS devices.
Mobile MUAs are often limited in rendering anything but the simplest MIME structured messages.
When I send something out, if anyone replies, it is delivered with my defined header and footer, but the body is an attachment which can't be read. It says, "No Application Available for This Content".
See https://wiki.list.org/x/4030707.
The issue is the message delivered from Mailman is structured like this:
multipart/mixed text/plain (msg_header) message/rfc822 (the original message with it's own MIME structure) text/plain (msg_footer)
and the mobile MUAs are saying they don't know how to render a message/rfc822 part. Actually, the appropriate application is the MUA itself and it may be possible for users to configure their devices so the MUA knows that. It should be shocking that the MUAs don't get that, but by now I expect it.
Aside: For Android I recommend K9 Mail by K9 Dog Walkers available from the Play Store or on GitHub at https://github.com/k9mail/k-9.
The above referenced article suggests solutions. If you don't need HTML or non-text attachments on your list, I suggest the following content filtering settings:
filter_content: Yes pass_mime_types: multipart message/rfc822 text/plain text/html collapse_alternatives: Yes convert_html_to_plaintext: Yes
which will ensure your messages are plain text only and allow adding msg_header and msg_footer to the body and not as separate MIME parts.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Mark Sapiro
-
rex@rexgoode.com
-
Stephen J. Turnbull