ned+ietf-822(_at_)mrochek(_dot_)com wrote:
Very unlikely, actually. CTE has always been extensible and has always allowed
X- tokens. The rules for handling unknown CTEs are also well defined.
Actually, there is a problem; the rule seems to be the following
from RFC 2045, section 6.4:
Any entity with an unrecognized Content-Transfer-Encoding must be
treated as if it has a Content-Type of "application/octet-stream",
regardless of what the Content-Type header field actually says.
That basically means that the content is treated as opaque. Obviously,
one cannot decode an unknown encoding, so that part of the CTE is
moot. But the other part, viz. the content domain (7bit, 8bit, or
binary) is unspecified. So an MTA presented with a message with
unknown CTE cannot tell (based on MIME header fields) whether or
not the next stage of transfer requires 8BITMIME or binary transport
or plain old 7bit transport.
I suppose the MTA in question could peek inside the message body to
determine the domain. Unless of course it's not all available (e.g.
it's in a stream too large to be held in memory) -- oops.
If compression is to be considered part of the CTE, then it is
certainly conceivable that some CTE may have binary domain, and
lacking explicit information an assumption of binary domain is
safe (it won't result in foisting incompatible content on the
next hop). OTOH if compression is considered a separate
attribute, then there doesn't seem to be much point in a CTE with
a binary domain other than "binary", and one could assume 8bit
domain for an unknown CTE.
The danger is that as both of the 2045-specified encodings (as
opposed to the identity CTE values) have 7bit domains, there may
be implementations that presume a 7bit domain for any unrecognized
CTE (if I were a gambler, I'd bet on it).