< It seems I'm going to be trying to tackle the problem of implementing a
< converter from 8BITMIME to 7bit. I have some comments on
< draft-ietf-822ext-ime-imb-01.txt from that perspective.
I've written a similar filter which goes both ways: 7-bit MIME to binary
MIME, and vice versa. (Unfortunately, I can't just send it out to the net.
Sigh.)
<< Mail gateways, relays, and other mail handling agents are commonly known
<< to alter the top-level header of an RFC 822 message. In particular, they
<< frequently add, remove, or reorder header fields. Such alterations are
<< explicitly forbidden for the encapsulated headers embedded in the bodies
<< of messages of type "message."
< This wording would seem to imply that if an agent had a message containing
< an message/rfc822 with 8-bit data in it, it could not convert it for
< transport over a 7-bit channel. The prohibition above would prevent the
< agent from modifying the Content-Transfer-Encoding: header imbedded in the
< message/rfc822, and it certainly can't apply a transfer encoding to the
< entire message/rfc822 itself.
I agree, the prohibition is too stringent. What I've had to do is to
recursively encode/decode the entire message/* segment, treating it the same
way I do the entire message. This has worked well so far.
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony