Messages in this thread | | | Date | Tue, 3 Oct 2000 21:55:33 +0300 | From | Matti Aarnio <> | Subject | Re: MIME QP encoded good/bad ... |
| |
On Tue, Oct 03, 2000 at 09:10:17AM -0700, Linus Torvalds wrote: > On Tue, 3 Oct 2000, Matti Aarnio wrote: > > > > Just FYI. THAT can't be MIME (quoted printable) error. > > Oh, but it is.
Oh, so you destroyed the evidence ? I see...
> > The '=' is very special in MIME QP, and as the '+=' at > > that very same line has not been turned into '+=3D', it > > wasn't QP encoding happenstance. > > That's simply because I caught the worst mime-damage, and missed the fact > that the "-" had also been damaged.
"-" isn't among characters to be QP encoded -- or then you will see EVERY character QP encoded, in which case you propably get BASE64 encoded attachment/body anyway. The encoded character was: "=AD" which at iso-8859-1 is listed as:
oct dec hex char description 255 173 AD SOFT HYPHEN
So right, it may LOOK like a hyphen/minus, but isn't it. Patch writer's bug. (And his/her mail program definitely considered the situation as "now I must QP encode everything".)
Linus, please use MUTT or PINE -- hmm... you do use PINE, so what is the problem at receiving MIME attachments, or QP encoded material at all ? (Aside of pine possibly saving/piping non-decoded QP text/plain message into file/pipe in original encoded form ? Hmm.. That is a though problem at the user agent...)
Some 10 years ago when MIME technology was being developed, our(*) goal was to make it as robust as possible. Unless your inbound email transport paths contain EBCDIC monsters, there really is no need complain about QP. (And not even then.)
(*) "our" as "the IETF MIME working group".
I do have technology which helps in cases where users are dead set to use non-mime understanding tools; those got created so that I myself could be lazy and use non-mime MUA 10 years ago, and still send and receive 8-bit iso-8859-1 character encoded email, like is our habit in Finland... (I write MTA software, not MUAs.)
Sendmail implemented something similar few years latter.
> Anyway, please avoid MIME if you can. Plain ascii is fine. > Linus
Yes Linus, ASCII is fine, but then the ENTIRE MESSAGE must be in 7-bit ASCII only. A single 8-bit char anywhere makes worlds of difference to the rules. (E.g. 8-bit char in .signature may force QP encoding of the entire message.)
You do need to have technology to grok (decode, I mean) QP encoded TEXT/PLAIN email transparently into your message store so that you never see any QP in it. If fact you propably have it, but it simply isn't enabled.
You actually have no option there. Your wishes won't change how people's MTAs and MUAs are working when they follow RFCs.
There may even be systems in between people and you, which don't announce capability to transport 8BITMIME so that some intermediate transport step is forced (per RFCs) to downgrade an 8BIT message to QUOTED-PRINTABLE. Most systems won't decode QP-email when sending it to systems announcing 8BITMIME capability. (And all qmail systems are lying -- they are not prepared to downgrade the message, if the remote system isn't announcing 8BITMIME capability. Also, qmail's aren't decoding any incoming QP in any case.)
Looking at Transmeta's neosilicon, I would say that you need at "Mlocal"/"Mpipe"/"Mfile" definitions to add "9" flag into "F=".
( Neosilicon is the MX defined server for transmeta.com ) ( I am now assuming that it does delivery to your local mailboxes -- which it possibly doesn't do... ) ( sendmail seems to have a bunch of "local" related "M" entries, all of those need to have the "9" added. )
This explanation matches sendmail 8.11, but neosilicon is 8.9.x, so "cavet emptor"...
9 If present, do limited 7->8 bit MIME conversions. These conversions are limited to text/plain data.
With that done, you won't complain about incoming MIME QP encoded TEXT/PLAIN messages (your local MTA decodes them for you), and when you receive an attachment of something, you can save/pipe that attachment properly decoded with your pine.
... which won't help in case of "soft hyphen" being incorrect character for the Makefile, but that is another issue.
/Matti Aarnio <matti.aarnio@zmailer.org> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |