On Thu, Mar 28, 2002 at 05:26:33PM +0100, Tony Earnshaw wrote:
| --
| tor, 2002-03-28 kl. 02:17 skrev Greg A. Woods:
| > This has nothing whatsoever to do with silly politics and mis-applied
| > analogies such as those you're trying to draw.
|
| This has nothing to do with "silly politics".
Then don't mention anyone by nation except for yourself. The rest of
Scandinavia and Europe seems to have no problem with quoted-printable
as a transport encoding for their utf-8 (or whatever) encoded text.
| It has everything to do with rfc1652.
I don't know that RFC. So I pulled it up and read the title.
SMTP Service Extension for 8bit-MIMEtransport
^^^^^^^^^
Notice that it is an ***extension*** and not part of SMTP itself.
Also notice this excerpt from section 3 :
If a server SMTP does not support the 8-bit MIME transport extension
(either by not responding with code 250 to the EHLO command, or by
not including the EHLO keyword value 8BITMIME in its response),
then the client SMTP must not, under any circumstances, attempt to
transfer a content which contains characters outside the US-ASCII
octet range (hex 00-7F).
A client SMTP has two options in this case: first, it may
implement a gateway transformation to convert the message into
valid 7bit MIME, or second, or may treat this as a permanent error
and handle it in the usual manner for delivery failures.
Given that, you'd be better off with mmdf than exim. exim does *not*
follow this standard. That is an intentional (and reasonable, IMO)
decision on Philip's part. If you want to be standards conforming and
interoperable with RFC821 and RFC2821 conforming mail servers, don't
set the 'accept_8bitmime' option.
| And rfc1428 and rfc2033 and rfc2045 and rfc2047 and rfc2277 and
I'm not going to bother looking these up right now; I've got real work
to do.
| rfc2821
RFC2821 says that only 7bit data is guaranteed to survive an SMTP
transfer.
| and rfc2822.
I'm not sure how this RFC is relevant to this discussion (I haven't
read it in-depth), but I know it allows for MIME. It allows you to
set a Content-Transfer-Encoding: header so that the receiving end
knows how to extract the high-order data from the message. It doesn't
help your argument.
| But especially with rfc1652, or has it been superceded? I can't find its
| successor.
|
| I'll try to explain.
|
| I want 8 BITMIME.
Too bad. Learn quoted-printable.
I want 16 BITMIME! Don't you care about the Japanese, Chinese,
Korean, and all the other "far-east" languages? Their alphabet can't
fit in 8 bit characters. UCS2 (Unicode) is 16 bits wide, so you
*must* support that, right? NO! I sent a message (to you) yesterday
containing unicode characters (including the euro symbol). It
survived the 7bit SMTP transfer just fine. How? First because I used
UTF-8 which turns the 16-bit characters into a well-defined series of
(8bit) bytes. Then I used quoted-printable to convert the series of
8bit bytes into a well-defined series of 7bit ASCII characters. All
the information regarding these encodings was cleanly included in the
message so that your mail reader (assuming it is standards conforming
as well) can transparently decode the message and display it for you
as it was intended.
| Phil Pennock don't want to give it to me.
Wrong again.
| His employer is my ISP.
That has nothing to do with Phil himself. If he doesn't do as his
boss tells him, he won't have any food on his plate and thus won't be
around (here or there) to help with exim.
| Exim and most other MTAs, on the contrary, do.
Err, no. Read the exim spec again :
However, though Exim is 8-bit clean, it is not a protocol
converter, and it takes no steps to do anything special with
messages received by this route. Consequently, this option is
turned off by default.
exim does not implement the 8BITMIME ESMTP extension. It allows you
to ask it to lie and pretend that it does, but you are asking for
trouble if you do that.
| Demon is NOT rfc1652 compliant.
Nor is exim.
| I could go on, but it serves no point.
You are correct. I will say no more on this matter (except for the
remainder of this message).
| > 8-bit SMTP data is a lost cause with no realistic benefit. Literaly
| > everyone who needs more than 7-bit ASCII can have access to multiple
| > implemntations of MIME in almost every conceivable environment.
|
| Trouble is, they don't choose to do so.
Oh, so here's the problem. The person who wrote that newsletter
doesn't understand the standards, and thus was not able to
interoperate with standard systems.
| Many Norwegian mail servers don't serve quoted-printable, and then all
| of this is useless. Worthless.
So take it up with those servers (actually, it's a problem with the
senders mail writer, not with the SMTP server itself) since that's
where the problem lies. The problem doesn't lie with demon.nl.
-D
--
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.
-- Dave Parnas
