On Apr 15, 2006, at 1:21 PM, Ken Irving wrote:
On Sat, Apr 15, 2006 at 09:17:33AM -0800, Ken Irving wrote:On Fri, Apr 14, 2006 at 10:33:58PM -0800, Ken Irving wrote:On Sat, Apr 15, 2006 at 12:28:25AM -0400, Gene Heskett wrote:And, how much screwing around would it be to make the listserver actualywrap it with the proper mimetype declaration?The SmartList (used for the debian lists) FAQ ends with: 8.13: Why are MIME and HTML emails a problem for SmartList? ... Body footer:Similar to the previous case, but here the text is injected after the final MIME separator, and so again doesn't belong to any ofthe MIME message parts. A proper MIME-aware text insertion recipe would have to knowhow to modify ALL of the text message segments without touchingany message segments which contain non-message text data, e.g. attachments. So it looks like it means fixing something, somewhere.SmartList is built around procmail, and formail is used to mung headers and such. I think in general the desire is to keep the email body intact, as received, so little, if any, body munging is done, other than simplyappending the debian unsub tagline. I can "imagine" some procmail^^^^^^^^ perlthat would identify a multipart message from the headers, grab theboundary string, and then open the body, seek to the terminating boundary delimiter, and insert another section to include the offending tagline. Any existing epilogue part included in the message would be retained. I think just the boundary lines would be needed (and associated blank lines), ascontent type and encoding would default to plain text. It's probably not so simple, though...
...but then, maybe it is. It looks like all the necessary info is present in the "Content-Type" header field.
If its value starts with "multipart" then extract its boundary marker declaration and process accordingly.
Otherwise append the trailer as beforeOne could also defensively add a clause for Content-Type matches "text".