メインコンテンツまでスキップ

8. SMTP トランザクション前後のダウングレード

重要な問題は,non-ASCII アドレス対応システムと ASCII を前提とする旧来システムの相互作用である.ASCII は国際化形式の適切な部分集合なので,国際化対応システムへ ASCII だけを送ることに問題はない.一方,対応システムが送るメールには,送信者,受信者,または双方の non-ASCII ヘッダー情報が含まれ得る.最初の SMTP サーバーが拡張をサポートしない場合,送信元システムは従来形式の envelope とヘッダーを送る,送信元利用者へ通知する,または [RFC2047] の encoded-word を使って手動で従来形式へダウングレードすることができる.変換には送信者と全受信者の ASCII-only アドレスが必要であり,その発見方法や MUA 等で行う変換は送信システムの設計事項で,本仕様の範囲外である.

初期設定システムがこれらの拡張機能をサポートする際に,より複雑な状況が発生しますが,SMTP送信チェーン内の後のサーバーには対応しません.前向きアドレスによる設定エラーが原因となる場合が多いことに注意してください.特にASCII以外のアドレスがホストされている場合,これらの拡張子を受け入れている最終配信MTAは,以下優先 MXホストで設定されず,送信されない場合.送信される唯一の非ASCIIアドレスがバックポインティングである場合 (例えば,SMTP MAILでは),受信者の設定は一般的に助けられない.一方,送信者向けの代替,すべてASCIIアドレスが送信環境または送信者によって権威的に知られているものである. したがって,これらの拡張を要求する中間 SMTP リレーが,チェーン内の次のシステムがそれらをサポートしていないことを発見した場合,メッセージを拒否または返却する以外に選択肢はほとんどありません.

上記のように,最初のメッセージ送信前にまたは中に ASCIIのみ形式に格下げが起こり得る.メッセージストア,IMAPまたは POPサーバー,または配信MTAとは異なる機能を持つクライアントに対応するために最終配信MTAへの配送後に発生することも可能である.これらのケースは以下のサブセクションで議論されます.

8.1. メッセージ送信前または送信中のダウングレード​

IETFは,従来のMUAの正確な行動を指定して,関連するユーザーインターフェースに最大限の柔軟性を提供することを避けています. SMTP標準 [RFC5321]第6.4節では,MUAと送信サーバーが,結果が公共インターネットに注射された後に"オン・ザ・ワイヤー"基準に適合する限り,ユーザーが提供できるものについて広い範囲を与えています.その伝統では,第8節の残りの部分での議論は,規範的な要求よりも一般的ガイドラインとして提供されています.

これらの拡張機能を必要とするメッセージは,時にはこれらの拡張機能をサポートしないシステムに転送される.最も一般的なケースは,ASCIIのみの前向き指向アドレスとASCII以外の後向き指向アドレスを組み合わせることでしょう.ここで説明されている拡張機能がインターネットメール環境で普遍的に実装されるまで,ヘッダーフィールド内の非ASCIIアドレス (または原始 UTF-8文字) を使用することを好む送信者は,意図された受信者が使用し,すべてのASCIIを使用することを期待する場合でさえ,発生するエラー条件について特に注意する必要があります.送信しないメッセージ (または送信サーバーからの他の指示) が定期的に落とされまたは無視される環境ではリスクは特に大きい.

国際化アドレスに対応する ASCII アドレスを見つけるのに最も便利なタイミングは,MUAまたは密接に関連したシステムにあるかもしれません.これはメッセージが送信される前に,またはメッセージの国際化形式が拒否された後に起こり得る.また,国際化形式から従来の ASCII 形式にメッセージを変換する最も便利な時間であり,または必要に応じて送信者に送送受信しないメッセージを生成する最も便利な時間です.その時点で,ユーザーはバックポインティングアドレスを変更し,代替アドレスのために意図されたバンドから離れた受信者に連絡し,適切なディレクトリを閲覧し,アドレスとメッセージコンテンツの両方を別の言語に翻訳する準備など,さまざまな選択肢があります. メッセージのダグラード化は 完全に自動化されたプロセスだと考えることは当然ですが, 通信を希望する少なくとも中程度の知能を持つユーザの能力を過小評価すべきではありません.

この文脈では,メッセージ送信サーバー (RFC 6409 [RFC 6409] で説明されているように) に変更を加え,ダウングレード操作またはアップグレードを行うように容易に想像できます.このような操作は,ここで議論されている国際化拡張機能の1つまたは複数のメッセージを受け取り,送信サーバーが遭遇する配信または次回の環境に対応するために,必要なように送信メッセージを調整することができます.

8.2. 最終 SMTP 配信後のダウングレードまたはその他の処理​

メールメッセージが最終配信MTAによって受信されると,通常何らかの形で保存されます.その後,保存されたフォームを直接読み取るソフトウェアによってまたは POPや IMAPなどの電子メール取得メカニズムを通じてクライアントソフトウェアによって回収されます.

7.1 節に記載されているSMTP拡張子は,輸送のみで保護を提供します. 保存された国際化アドレスおよび UTF-8 メッセージヘッダを理解するためにアップグレードされていない MUA および電子メール取得メカニズムが,保存された国際化メールにアクセスすることを妨げません.

最終配送MTA (または,より具体的には,対応するメールストレージエージェント) は,電子メールストレージにアクセスするエージェントが常にここで提案された拡張機能に対応できると安全に仮定できないため,国際化されたメールをダウングレード,これらの拡張機能を使用するメッセージまたは両方の特定することが可能である.これらのいずれかまたは両方のアクションが実行される場合,最終配送MTAは,情報損失なしに元の国際化されたフォームを保存または回復するためのメカニズムを含む必要があります. SMTPUTF8認識のエージェントによるアクセスをサポートするために,その情報の保存は必要である.