電子メールサーバ(MTA)が利用者が意図しない、中継(中継時の文字コードの 変換等)を行なった場合にどの様な影響があるだろうか。 　インターネットで電子メールを交換するときの文字コードは電子メールを配送するときに使用される、 配送コードと端末で表示するときに使用する内部コードの二つに分けられる。 　配送コードはMUA,MTA間、MTA,MTA間で使用される文字コードであり、日本国内では一般にISO-2022-JPコードが用いられている。 　内部コードはコンピュータが内部で処理するために使用する文字コードである。一般的にはパソコンではShiftJis、 Unix等のワークステーションではEUCが使用される場合が多い。 　ここで、問題になるのは配送コードと内部コードが異なることである、この問題は配送コードを実際に表示、 メッセージ作成等の処理を行うコンピュータが配送コードを直接処理できないことである。 内部コードはコンピュータのオペレーティングシステムやアーキテクチャによって異なるので、 複数の文字コードが存在する。 　このため、一部の古い、MTAでは配送コードを内部コードに変換するMTAも存在したが、 現在ではそれほど数は多くないと思われる。 　現在問題になるのはMUAから送信されたメッセージをMTAがQエンコーディング、 Bエンコーディング等を行ってしまう問題である。 　具体的にはMUAがMTAに対してShiftJisコードでメッセージを送信したとすると、 MTAでは、配送時に7bitコードで配送しようとしてShiftJisの文字コードをQエンコーディングに 変換してしまう場合がある。また、このときにMUAがMIMEのContent-Type: charset: に対して正しく charsetを指定して入れば問題は発生しないが、このcharsetを正しく設定していない場合はMTAが標準と しているcharsetを自動的にセットさせる可能性がある。このような処理を行われると、 受信した側では元の電子メールの文字コードが何であったのか判断がつかないないために表示できないといった問題が発生する。 　このような場合でも仮にメッセージが日本語だけと限定されていれば比較的、 元の文字コードを推測することは容易であるが現在のインターネットのコミュニティを 考えると文字コードを日本語だけと限定することは危険である。
また、これらの文字コードの変換やエンコーディング方式の変更が行われると、 先に説明した電子署名を行なった場合に内容の改竄とみなされ正しく検証できない。 　この問題は電子署名は内部コードではなく、配送コードに対してハッシュ値を求め署名を 作成されるので、エンコーディング方式の変換だけでなく、実際にはMUAが受信したメッセージを ハードディスクに保存する際に配送コードから内部コードに変換して保存した場合にも発生する。 この問題は日本語でも以下の場合に発生するのでMUAでは極力文字コードの変換は行うべきではない。 　現在日本でも一般的に電子メールではISO-2022-JPコードが使用されている。 このコードはいわゆるJISコードでESCから、はじまる3byteで使用するコードの状態推移を行なっている。 以下のESCからはじまるシーケンスが使用されている。 ESC ( B ASCII ESC ( J JIS X 0201-1976 ESC $ @ JIS X 0208-1973 ESC $ B JIS X 0208-1983 　内部コードにShiftJisコードを使用しているパソコンを使用している場合、 JIS X 0208-1973を使用して作成されたメッセージに対して電子署名がされていた場合にこの JIS X 0208-1973コードをShiftJisコードに変換してしまうと、メッセージに持ってた、 JIS X 0208-1973への推移コードESC $ @の情報が失われてしまうために、このメッセージが本来、 JIS X0208-1973で作成されていたのか、JIS X 0208-1983で作成されていたのかの情報が失われてしまい、 電子署名が正しく検証できなくなってしまう。 この問題は内部コードにEUC等、他の文字コードを使用してる場合でも 同様の問題が発生するので注意が必要である。