> > I've got some clients that are really simple and don't understand > > various > > message encoding types, such as quoted-printable, base64, possibly > > others. > > They understand plain text only. So, for users in specific domains, > > I'd > > like to convert quoted-printable, base64 and possibly other encoded > > messages > > to plain text. > > Do you understand why QP, Base64, and other encodings exist?
Yes > > It is because some messages cannot be represented as plain text, due to > the fact that "plain text" for email is a subset of the US-ASCII > character set. QP and Base64 exist to translate 8-bit characters and > arbitrary binary data into a stream of 8-bit characters that are in a > 'mail safe' subset of US-ASCII. Yup. But if the original message content is all plain text, then the encoding adds no value and can be removed without changing the message. > > I presume I need a content-filter to perform this work post-queue. > > One actually should only do anything like this with client-side > software. You presumably intend to throw away information (such as the > difference between o, ô, and ö) Yes. Although the likelihood of such characters in the original content is virtually nil in this application. And, even if it does exist, such characters can't be used by the receiving client anyway. > and it is best to allow those choices > to remain with end users. Generally true. But not in this case. The client is what it is. So I either find a way to decode such messages externally before delivering them to the client, or else the messages can't be read at all (at least the base64 type). > > I looked here: http://www.postfix.org/addon.html > > > > . but didn't see anything that addresses the issue. Any ideas would > > be > > helpful. > > Or maybe not, as I'm entirely serious when I say that your best choice > is to not do this. Solve whatever problem you are trying to solve in > some other way. I understand and appreciate what you're saying as a general rule. But I also understand this particular application. And for this particular application, recovering the original plain text message before sending to the client is what's needed. But thanks for your thoughts, Bill. Your postings on this list are always informative. Michael
