1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
1.2. 本文書で使われる慣例
本文書中の以下の用語(訳注:訳文では大文字部分の原文を( )内で示している。)
“…しなければならない(MUST)”
“…してはならない(MUST NOT)”
“…の必要がある(REQUIRED)”
“(当然)…するものとする(SHALL)”
“(当然)…しないものとする(SHALL NOT)”
“…すべきである(SHOULD)”
“…すべきではない(SHOULD NOT)”
“…が推奨される(RECOMMENDED)”
“…してもよい(MAY)”
“…を選択してもよい(OPTIONAL)”については、[RFC-2119]の記述に従って解釈すること。This document is concerned with the portion of a mail message commonly called "envelope sender", "return path", "reverse path", "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are either not well defined or often used casually, this document defines the "MAIL FROM" identity in Section 2.2. Note that other terms that may superficially look like the common terms, such as "reverse-path", are used only with the defined meanings from normative documents.本文書はメールメッセージ中の、一般に「エンベロープ送信者」、「返信経路(return path)」、「返送経路(reverse path)」、「宛先不明のため返送(bounce)アドレス」、「2821 From」、「MAIL FROM」などと呼ばれる部分に関するものである。上記の用語は定義が不十分であるか適当に使われることが多いため、本文書では2.2で“MAIL FROM”アイデンティティを定義する。表面的には同義語に見える他の用語(たとえば「返送経路」)は、標準文書で定義された意味でのみ使用する。
2. Operation
2.1. The HELO Identity
The "HELO" identity derives from either the SMTP HELO or EHLO command (see [RFC2821]). These commands supply the SMTP client (sending host) for the SMTP session. Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF clients must be prepared for the "HELO" identity to be malformed or an IP address literal. At the time of this writing, many legitimate E-Mails are delivered with invalid HELO domains.
2. 運用
2.1. HELOアイデンティティ
“HELO”アイデンティティは、SMTPのHELOコマンドまたはEHLOコマンドに由来する([RFC2821]を参照)。これらのコマンドはSMTPセッション中にSMTPクライアント(送信ホスト)に提供される。EHLOコマンドまたはHELOコマンド中に提示されるドメインについての要求は必ずしも送信側に明らかにされないため、“HELO”アイデンティティの形式が不正な場合やIPアドレスがそのまま使われている場合にはSPFクライアントが対処しなければならない。本文書執筆時点では、多くの正当な電子メールには無効なHELOドメインが使われている。
It is RECOMMENDED that SPF clients not only check the "MAIL FROM" identity, but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the <sender>.SPFクライアントは“MAIL FROM”アイデンティティを検査するだけでなく、別個に“HELO”アイデンティティを検査することが推奨される(RECOMMENDED)。その場合は、“HELO”アイデンティティを <sender> として check_host() 関数(4章)を適用する。
2.2. The MAIL FROM Identity
The "MAIL FROM" identity derives from the SMTP MAIL command (see [RFC2821]). This command supplies the "reverse-path" for a message, which generally consists of the sender mailbox, and is the mailbox to which notification messages are to be sent if there are problems delivering the message.
2.2. MAIL FROMアイデンティティ
“MAIL FROM”アイデンティティは、SMTP MAILコマンド([RFC2821]を参照)に由来する。このコマンドはメッセージに“reverse-path”を提供する。“reverse-path”は、通常は送信者メールボックスかつ、メッセージ送信に問題がある場合に通知メッセージが送られるメールボックスである。
[RFC2821] allows the reverse-path to be null (see Section 4.5.5 in RFC 2821). In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document defines the "MAIL FROM" identity to be the mailbox composed of the localpart "postmaster" and the "HELO" identity (which may or may not have been checked separately before).[RFC2821]は何も入っていないreverse-pathを認めている(RFC2821の4.5.5を参照)。この場合、送信者メールボックスとして明示されるものがないので、このようなメッセージはメールシステム自体からの通知メッセージと仮定できる。reverse-pathに何も入っていない場合、本文書は“MAIL FROM”アイデンティティを、ローカル部分(@より前の部分)が”postmasterで、ドメイン部分が“HELO”アイデンティティ(事前に個別に検査されているにせよ、しないにせよ)で構成される、と定義する。
[Page 5]
《PREV》 |