>
> * Many many eons ago, there used to be some machines which used 7 bit
> characters (in order to pack 5 of these into their 36 bit
> words). Obviously, those wouldn't support 8 bit characters. Let's call
> them type A MTA's.
Interesting theory, but it doesn't matter why, defacto the RFC mandates
7-bit messages, or the use of MIME. C'est tout, qu'est important. So actually
8-bit MTA's that don't do MIME (8BITMIME extension), but just do forward
plain 8-bit mails are broken and should be fixed.
> What are we seeing now? QP is trying to work around the problem
> caused by other mailers. I believe that most of these troublesome
> mailers are of type B, D, F (misguided workarounds) rather than A
> (real hardware mandated restrictions). Now, QP proponents urge
> everybody who doesn't understand QP to upgrade. Why not simply urge
> those people who still have type A, B, C, D, E and F MTA's to upgrade?
> These MTA's are rare (less people affected), and older (more in need
> of an upgrade anyways).
Because, before you can urge someone to upgrade to a 8-bit MTA, you have
to upgrade to our standards (RTFRFC's). So if you want to do 8-bit
mailing, please follow the standard, and don't solve it the french way.
(8-bit plain Emails don't solve all problems, they don't tell you the
character encoding.)
>
> In a few years we will see another super-duper "standard" intended to
> protect messages from QP. When will people understand that a
Why? Just use RFC-complainant software. Then you have NO problems
> pessimistic strategy for mailers is a bad idea? It may solve problems
> now, but it will become a problem itself later.
>
> The people who created the MIME standard were probably all bright and
> intelligent people, and had the best intentions. However, some
> problems can't be foreseen easily, and only become apparent in
> hindsight when the system is widely used. QP is one of these
> cases. For pure text messages, it's not that big of a problem, because
> the human brain can 'fill in the blanks' left by cryptic =XO=YE
> sequences, if present in reasonable quantities. The = sign was
> probably chosen as an escape character because it occurs only rarely
> in text messages. The problem becomes apparent when the text is
> intended to be machine readable. This kind of text becomes vulnerable
But then you run trough mmencode, don't you?
> to word wrap, character replacement etc, and also contains a much
> higher percentage of = signs than prose. It was probably not foreseen
> either that some countries use a 'mostly 7 bit' character set, which
> features *one* single 8 bit character. And, tough luck, that's a
> character which usually occurs near numbers... And its QP code ends
> with a digit... Arghhh!
So what? There mmencode. You know what bothers me? Not MIME, but the near
monopoly of some companies in the WWW-browser market.
>
> Yes, these problems can be worked around by fixing up these
> characters manually or by installing filters that tranform the texts
> back to a readable format. However, why should anybody be forced to
> make that extra effort, which would be totally unneeded without that
> =/exon/=ing QP encoding ?
He is not. As long as the Email doesn't contain 8-bit chars, or all MTA's
along the path from source to destination support 8-bit transfers. In any
other context, he has to complain to the sender and/or to the MTA's along
the path, not to a mailer that follows the standards.
[*screammode on*] STANDARDS [*screammode off*] is here the KEYWORD. I
see, that this may be a bit of a problem for some (I didn't say la
Francophonie, :) ) people :(
>
>
> >Protecting the contents of the message (via quoted-printable or base64
> >encoding) will *prevent* the problem of 7bit MTAs choking on 8bit data.
Correct. And it is a standard!
Andreas
-- Andreas Kostyrka Email: andreas@medman.ag.or.at Fax: +43/1/7070750 Tel: +43/1/7077571, +43/664/3020166 (cellular) Copyright 1996 Andreas Kostyrka. Microsoft Network is prohibited from redistributing this work in any form, in whole or in part.