If these tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server SHOULD reject the message and when rejecting MUST use "550 5.7.1 Submitter not allowed."これらのテストの結果、接続しているSMTPクライアントがSUBMITTERドメインを代表して電子メールメッセージを伝送する権限を持っていないとわかった場合、受信側SMTPサーバはメッセージを拒否すべきであり（SHOULD）、拒否の理由としては“550 5.7.1 Submitter not allowed.（投函者を認められない）”を使わなければならない（MUST）。
If the receiving SMTP server allows the connecting SMTP client to transmit message data, then the server SHOULD determine the purported responsible address of the message by examining the RFC 2822 message headers as described in [PRA]. If this purported responsible address does not match the address appearing in the SUBMITTER parameter, the receiving SMTP server MUST reject the message and when rejecting MUST use "550 5.7.1 Submitter does not match header."受信側SMTPサーバが接続しているSMTPクライアントにメッセージデータの伝送を許可する場合、サーバは［PRA］に記述されているようにRFC2822メッセージヘッダの検査によって、メッセージのPRAを決定すべきである（SHOULD）。このPRAがSUBMITTERパラメータのアドレスと一致しない場合、受信側SMTPサーバはメッセージを拒否しなければならず（MUST）、拒否の理由としては“550 5.7.1 Submitter does not match header.（投函者がヘッダと一致しない）”を使わなければならない（MUST）。
If no purported responsible address is found according to the procedure defined in [PRA], the SMTP server SHOULD reject the message and when rejecting MUST use "554 5.7.7 Cannot verify submitter address."［PRA］で定義されている手続きに従ってPRAが見つからない場合、SMTPサーバはメッセージを拒否すべきであり（SHOULD）、拒否の理由としては“554 5.7.7 Cannot verify submitter address.（投函者アドレスを検証できない）”を使わなければならない（MUST）。
Verifying Mail Transfer Agents (MTAs) are strongly urged to validate the SUBMITTER parameter against the RFC 2822 headers; otherwise, an attacker can trivially defeat the algorithm.MTAの検証にあたっては、RFC2822ヘッダに対してSUBMITTERパラメータを確認することを強く推奨する。この方法をとらない場合、攻撃者がアルゴリズムを簡単に破れてしまう。
Note that the presence of the SUBMITTER parameter on the MAIL command MUST NOT change the effective reverse-path of a message. Any delivery status notifications must be sent to the reverse-path, if one exists, as per Section 3.7 of [SMTP] regardless of the presence of a SUBMITTER parameter. If the reverse-path is null, delivery status notifications MUST NOT be sent to the SUBMITTER address.MAILコマンドにSUBMITTERパラメータが存在しても、メッセージの有効なreverse-pathを変更してはならない（MUST NOT）。SUBMITTERパラメータの有無にかかわらず、［SMTP］の3.7で定義されているように、reverse-pathが存在する場合、配送状態通知をreverse-pathに送らなければならない。reverse-pathが空の場合、配送状態通知をSUBMITTERアドレスに送ってはならない（MUST NOT）。
Likewise, the SUBMITTER parameter MUST NOT change the effective reply address of a message. Replies MUST be sent to the From address or the Reply-To address, if present, as described in Section 3.6.2 of [MSG-FORMAT] regardless of the presence of a SUBMITTER parameter.同様に、SUBMITTERパラメータはメッセージの有効な返信アドレスを変更してはならない（MUST NOT）。SUBMITTERパラメータの有無にかかわらず、［MSG-FORMAT］の3.6.2に定義されているように、FromアドレスまたはReply-Toアドレスが存在する場合、返信はFromアドレスかReply-Toアドレスに送らなければならない（MUST）。
4.3. Transmitting to a Non-SUBMITTER-Aware SMTP Server
Notwithstanding the provisions of Section 4.1 above, when an MTA transmits a message to another MTA that does not support the SUBMITTER extension, the forwarding MTA MUST transmit the message without the SUBMITTER parameter. This should involve no information loss, since the SUBMITTER parameter is required to contain information derived from the message headers.
4.3. SUBMITTERに対応していないSMTPサーバへの転送
上記4.1の条件にかかわらず、あるMTAがSUBMITTER拡張をサポートしていない別のMTAにメッセージを転送する場合、転送側のMTAはSUBMITTERパラメータをつけずにメッセージを転送しなければならない（MUST）。SUBMITTERパラメータを除いても情報が失われることにはならない。SUBMITTERパラメータに含まれる情報は、メッセージヘッダから導出されるものでなければならないからである。
5. Examples
This section provides examples of how the SUBMITTER parameter would be used. The following dramatis personae appear in the examples:alice@example.com: the original sender of each e-mail message.bob@company.com.example: the final recipient of each e-mail.bob@almamater.edu.example: an e-mail address used by Bob that he has configured to forward mail to his office account at bob@company.com.example.alice@mobile.net.example: an e-mail account provided to Alice by her mobile e-mail network carrier.
5. 例
本章では、SUBMITTERパラメータの使用方法の例を提供する。例には以下の人物が登場する：
alice@example.com：電子メールメッセージの最初の送信者。
bob@company.com.example：電子メールの最終的な受信者。
bob@almamater.edu.example：ボブの使っている電子メールアドレス。会社のメールアカウントbob@company.com.exampleへメールを転送するように設定してある。
alice@mobile.net.example：アリスがモバイル電子メールネットワークキャリアから提供されている電子メールアカウント。
[Page 6]
| 《PREV》 |