From: Ian Bell (ianbell@turnpike.com)
Date: Mon Sep 30 2002 - 08:36:13 CDT
On Fri, 27 Sep 2002, Charles Lindsey <chl@clw.cs.man.ac.uk> wrote:
>In <3QDMy9uJEwk9IADY@pillar.turnpike.com> Ian Bell
><ianbell@turnpike.com> writes:
>
>
>>On Wed, 25 Sep 2002, Charles Lindsey <chl@clw.cs.man.ac.uk> wrote:
>>>
>>>Indeed so, but hardly any servers do that conversion, even though they
>>>claim to be 8BITMIME compliant.
>
>>How do you know that? You say that it is exceedingly rare to encounter a
>>server that doesn't offer 8BITMIME, so how have you tested
>>down-conversion?
>
>My knowledge comes from what I have seen reported on this and other lists.
[]
>>Or are you confusing "8bit clean" with 8BITMIME support? The former may
>>just not bother testing for 8bit content before relaying or delivery:
>>the latter should be applying the rules.
>
>What I hear is that there are a significant number of systems that are
>8bit clean, that do not test and downgrade when relaying to non-8BITMIME
>systems, but which nevertheless report "8BITMIME" in response to EHLO.
So what you hear is that there are enough systems that are 8bit clean or
are (broken) 8BITMIME implementations that don't care whether the next
hop advertises 8BITMIME or not.
But what you said:
"[smtp] provides guaranteed 8-bit transport within bodies when
8BITMIME is supported[]. That includes the headers of MIME
multiparts"
is just not true. There is no such guarantee.
Compliant 8BITMIME implementations do not guarantee 8bit end-to-end
transport at all, and they most certainly don't make any guarantees
about encapsulated 8bit headers. This statement gives the impression
that MIME-compliant MUAs are allowed to send 8bit headers to 8BITMIME
servers - they aren't.
-- Ian Bell T U R N P I K E