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/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:12 EST