> Kai Henningsen: "Re: vger *should* produce quoted-printable" (Feb 25,
> >0:52):
> > You are looking at one part of the picture only, and pointing out that it
> > doesn't look good. Big surprise there.
> >
> > The whole picture is like this:
> >
> > Besides QP, there is 8BITMIME.
>
> No.
>
> People have told me about 8BITMIME, and yes, I know about it.
>
> But it's actually not relevant to this, because it's the SAME problem.
Hey, that's *why* it is relevant here.
> Both QP and 8BITMIME are there to perpetuate an old standard that should
> never have been there in the first place, and should not be supported or
> excused these days.
8BITMIME is most definitely *not* there to perpetuate 7 bit SMTP, which I
assume is what you are speaking about. That notion is ridiculous - the
opposite is true!
> (The reason I picked on QP was that that was what was being discussed:
> the same arguments hold against 8BITMIME as it's really the same thing).
They don't hold.
> > The idea is that, over time, most mailers will implement 8BITMIME. When
> > this has happened, there will no longer be a reason to use QP; simply use
> > 8 bit and it will work.
>
> Right. As with QP, it's a cludge, and as with QP, people excuse
Umm ... just how is it a kludge?! Is this a troll?
> themselves by saying "use the right tools and you won't even see the
> problem".
Remember, that's just about what you said yourself.
> The reason I don't like QP (8BM) is that it doesn't fix the problem, it
8BM *does* fix the problem.
> works around it. These standards are broken, because it allows your
> average lazy person to _continue_ using 7-bit mailers. THAT is why I
8BITMIME is currently at the "draft standard" stage. Judging from other
SMTP extensions, it will become a "recommended" standard. That's exactly
the same sort of standard that SMTP itself is.
I fully expect that, in a few years, all serious mailers (like, say,
sendmail, smail, zmailer ...) will support it.
It then becomes a question of getting people to upgrade to the newest
version. That's a problem you're not going to avoid anyway.
> hate QP. THAT is why I likened QP to giving painkillers to a cacher
> patient instead of trying to get rid of the cancer in the first place.
In my opinion, that's nonsense. QP is like giving someone with a broken
leg crutches; 8BITMIME is healing the leg.
Pain killers would be the "solution" proposed by some other people: simply
try to ignore the problem that the mail system is not 8 bit clean. *That*
would perpetuate the problem.
> What the 8-bit standard SHOULD have done would have been to make _one_
> very simple new RFC: a RFC that updates the old mail RFC's and requires
> mailers to be 8-bit clean. PERIOD. None of this 8BITMIME and QP sh*t.
And what do you do the next time you want to change something? It's just
like the files in /proc: define a useful expansion mechanism once and for
all, or get growing pains each time you want to change something.
The next transparency change, by the way, is already on the road - expand
SMTP to handle real binary messages instead of lines of text. IIRC, they
use length-data there instead of point-escaped lines.
Lesson: do it right, define ESMTP. Don't use the sort of kludge *you*
propose.
> That would have forced vendors to actually _fix_ their setups in order
> to be able to say that they comply with the RFC's.
>
> Because the RFC's didn't do that, I cannot complain to anybody who is
> having a 7-bit mail gateway, because the jerk who is in charge of that
> stone-age piece of machinery will just point to the RFC's and say
> "nyaah, nyaah, it's _your_ problem". THAT is why the whole philosophy
> behind QP and 8BITMIME is so broken.
That is something an Internet standard will *never* do, making most
existing standards conformant software unconformant from one day to the
next. It would be pretty stupid, too - it's a very small step from there
to ignoring RFCs alltogether.
Remember, there's no police behind the RFCs. They have to be accepted.
Getting standards accepted is hard enough without pissing off the people
you want to convince.
Besides, when 8BITMIME has been a recommended standard for a few years
(and probably been widely deployed), *then* you have a chance to get the
hosts requirement RFCs updated to say "everyone MUST do 8BITMIME".
> And THAT is why I'd advocate sending 8-bit mails regardless of whether
> the receiver tells you he accepts them or not. In most cases, 8-bit
> mails will actually go through an old mailer too (ironic - it actually
For some values of "most". I've seen lots and lots of mailers that mangled
8 bit mail, sometimes even 7 bit mail, very badly.
It you count not installations, but implementations, my guess would be
that most mailers don't do it right; and I'm not so sure about the
installations either.
> works _better_ if you ignore the standards), and if they don't, we can
> at least _hope_ that the maintainer of that site will upgrade his
> software.
This argument will be just as right for mailers following the standards.
MfG Kai