4. Select all the non-empty From headers in the message. If there is exactly one such header, continue with step 5. Otherwise, proceed to step 6.ステップ4：
メッセージ中の空でないFromヘッダをすべて選択する。該当するヘッダが1個だけの場合はステップ5に進む。その他の場合はステップ6に進む。
5. A previous step has selected a single header from the message. If that header is malformed (e.g., it appears to contain multiple mailboxes, or the single mailbox is hopelessly malformed, or the single mailbox does not contain a domain name), continue with step 6. Otherwise, return that single mailbox as the Purported Responsible Address.ステップ5：
前のステップでメッセージからヘッダが1個選択されている。そのヘッダの形式が不正な場合（例：複数のメールボックスを表示している場合、メールボックスは1個だが形式が不正で解析できない場合、メールボックスにドメイン名が含まれていない場合など）はステップ6に進む。その他の場合は、表示されている単一のメールボックスをPRAとして返す。
6. The message is ill-formed, and it is impossible to determine a Purported Responsible Address.ステップ6：
メッセージの形式が不正なため、PRAの決定は不可能である。
For the purposes of this algorithm, a header field is "non-empty" if and only if it contains any non-whitespace characters. Header fields that are otherwise relevant but contain only whitespace are ignored and treated as if they were not present.このアルゴリズムの目的にとって、ヘッダフィールドが「空でない」ということは、空白以外の文字を含んでいる場合だけに限られる。他の部分では同一のヘッダフィールドでも、
空白しか含まれていない場合は無視され、存在しないと同様に扱われる。Note that steps 1 and 2 above extract the Resent-Sender or Resent- From header from the first resent block (as defined by section 3.6.6 of [RFC2822]) if any. Steps 3 and 4 above extract the Sender or From header if there are no resent blocks.上記のステップ1および2では、（［RFC2822］の3.6.6で定義されている）メッセージ冒頭の再送ヘッダ部分からResent-SenderヘッダまたはResent-Fromヘッダを抽出している。上記のステップ3および4では、再送ヘッダ部分が存在しない場合にSenderヘッダまたはFromヘッダを抽出している。
Note that what constitutes a hopelessly malformed header or a hopelessly malformed mailbox in step 5 above is a matter for local policy. Such local policy will never cause two implementations to return different PRAs. However, it may cause one implementation to return a PRA where another implementation does not. This will occur only when dealing with a message containing headers of questionable legality.上記のステップ5で、不正で解析不能なヘッダやメールボックスとは何かについては、ローカルのポリシの問題である。ローカルポリシが原因で2つの実装が異なるPRAを返すことはない。ただし一方の実装がPRAを返し、他方の実装はPRAを返さない結果になるかもしれない。この問題は、正当性の疑われるヘッダを含むメッセージを扱う場合にのみ起こる。
Although the algorithm specifies how messages that are not in strict conformance with the provisions of RFC 2822 should be treated for the purposes of determining the PRA, this should not be taken as requiring or recommending that any systems accept such messages when they otherwise would not have done so. However, if a liberal implementation accepts such messages and desires to know their PRAs, it MUST use the algorithm specified here.このアルゴリズムは、PRAを決定するために、RFC2822の規定に厳密には適合しないメッセージを扱う方法を定義しているが、システムがPRA決定以外の場合には受け入れないメッセージの受け入れを要求したり推奨していると解釈すべきではない。しかし、許容度の高い実装がこのようなメッセージを受け入れて、PRAを知りたい場合には、上記で定義されているアルゴリズムを用いなければならない（MUST）。
Where messages conform to RFC 822 rather than RFC 2822, it is possible for the algorithm to give unexpected results. An RFC822 message should not normally contain more than one set of resent headers; however, the placement of those headers is not specified, nor are they required to be contiguous. It is therefore possible that the Resent-From header will be selected even though a Resent- Sender header is present. Such cases are expected to be rare or non-existent in practice.RFC2822ではなくRFC822に準拠したメッセージの場合、アルゴリズムが予期しない結果を出す可能性がある。RFC822メッセージは通常、複数の再送ヘッダ群を含むべきではないが、再送ヘッダの配置については定義されていない。そのため、Resent-Senderヘッダが存在している場合でもResent-Fromヘッダが選択されてしまう可能性がある。実用においては、このような事態はほとんど起こらないと予想される。
[Page 4]
| 《PREV》 |