dhananjay <dhananjay(_at_)zlemail(_dot_)com> wrote:
If remote MTA does not support 8bit MIME, then the sender MTA should
convert message from 8 bit to 7 bit and send the message. Now, there
can be 3 approaches (apart from perm error NDR generation) that I am
aware of :
1. The sender MTA should first convert whole message to original
encoding
For the five content-transfer-encodings defined by RFC 2045, this is
a no-op. (For 8bit or binary, the conversion is just the identity
function, which is a no-op. For 7bit, base64, or quoted-printable, the
message doesn't need 8BITMIME anyway, so just send it.)
I guess you must be concerned about how to handle other
content-transfer-encodings, besides the five defined in RFC 2045. In
that case, I guess you're right, you need to undo it and then apply an
encoding that yields a 7bit output (like base64 or quoted-printable).
Perhaps this suggests that any new content-transfer-encoding that
produces 8bit output should be co-designed with a 7bit sibling, so that
there would be a shortcut from one to the other. For example, maybe
the 8bit version should limit its line length to 747 bytes rather than
998, so that the 7bit version could be the same thing except that each
line is base64-encoded. Then it would be easy to convert directly from
either one to the other.
AMC