Edit

Page

Page title:

Page body:

[2] [CODE[Received:]] 欄は、普通[[電子メイル]]で使って、配送の記録が行われる欄です。
他に、電子ニュースでもかつてはつかわれていました。

* 仕様書

[REFS[
- [36] [CITE@en[RFC 5321 - Simple Mail Transfer Protocol]] ([TIME[2016-01-10 14:43:30 +09:00]] 版) <https://tools.ietf.org/html/rfc5321#section-4.4>
]REFS]

* 電子メイルにおける Received: 欄

[3] 配送の各段階の数だけどんどん追加されていきます。
メイルがどのような経路で配送されたのかやどのサーバーが不調なのかなどの追跡に使用出来ます。
(現在では途中経路を数 hop も経ないで直接サイトからサイトに配送されるのが普通ですし、途中の経過サイトの不調のための遅延もかなり稀ですが、昔はよくあることでした。)

- [[RFC822]] (822 旧仕様)
- [[RFC2822]] (822)
- [[RFC821]] (SMTP 旧仕様)
- [[RFC2821]] (SMTP)

[5] [[RFC2822]] は一般的な [CODE[Received:]] 欄の構文を規定しています。
[[RFC2821]] ([[SMTP]]) は、 SMTP サーバーが [CODE[Received:]]
欄に記録すること及びその書式を規定しています。 RFC 2821 の構文は
RFC 2822 のものより具体的・厳格になっています。

RFC 2822, RFC 2821 の旧版である [[RFC822]], [[RFC821]]
についても同じような関係がありますが、 2822/2821 程はっきり分化してはいません。

[[#comment]]

** 値

- by = domain
- for = addr-spec / "<" [route] addr-spec ">"
- from = domain
- id = word / msg-id
- via = "TCP" (2821) / "UUCP" (2821) / iana-atom 
/ "smtptcp" / "TELNET" (821) / "DDN" / "ARPANET/MILNET" / "EUnet"
- with = "ESMTP" (2821) / "SMTP" (2821) / iana-atom 
/ "X25" (821) / "TCP/SMTP" / "Mailnet" / "BSMTP"

昔は結構すきなよーな値を入れてたらしい。

"BSMTP" [[BITNET]] 版 [[SMTP]]?

- [11] [[RFC1428]] は値 [CODE[convert]] を規定しています。 "rfc822-to-8bit", "rfc822-to-base-64" or "rfc822-to-quoted-printable"

[14]
[SAMP(822)[with QMQP]]: [[QMQP]] — Quick Mail Queueing Protocol [djb]
ってのもしばしば使われている模様。
([[名無しさん]] [WEAK[2004-07-11 01:06:33 +00:00]])

[15]
[CODE(822)[from unknown]] ってのも昔からよく見かけます。
([[名無しさん]])

[16]
[SAMP(822)[with internal]] なるものも使われています。
([[名無しさん]] [WEAK[2004-07-11 01:08:13 +00:00]])

[37] [CODE[SMTP]] と [CODE[ESMTP]] の値の意味は [[RFC 5321]]
には明記されていません。いつどちらを使うべきかは明らかではありません。

[17]
[SAMP(822)[via csmap]]
([[名無しさん]] [WEAK[2004-07-11 01:10:29 +00:00]])

[38] [CODE[VIA]] は省略されることが多いようです。 [CODE[VIA TCP WITH SMTP]]
と書いてもほとんど意味が無いからでしょう。

[18]
こういうとんでもなのもあった: [SAMP(822)[with Microsoft SMTPSVC(5.0.2195.6824)]]
([[名無しさん]] [WEAK[2004-07-11 01:26:00 +00:00]])

[19]
[CODE(822)[WITH]] の値に6月に色々追加されています。典拠は RFC-to-be です。

追加されたのは
[CODE(822)[ESMTPA]], [CODE(822)[ESMTPS]], [CODE(822)[ESMTPSA]], [CODE(822)[LMTP]], [CODE(822)[LMTPA]], [CODE(822)[LMTPS]], [CODE(822)[LMTPSA]], [CODE(822)[ESMTP]] です。 [CODE[A]] は [[SMTP AUTH]], [CODE[S]] は [[TLS]], [CODE[LMTP]] は [[LMTP]] です。 [CODE(822)[ESMTP]] は [Q[ESMTP with NO-SOLICITING]] と書いてありますが、既に [Q[SMTP with Service Extensions       [RFC2821] ]] が登録されているので、何かの間違いでしょう。

([[名無しさん]] [WEAK[2004-07-11 02:39:26 +00:00]])

[20]
''MAIL Parameters'' <http://www.iana.org/assignments/mail-parameters>
([[名無しさん]] [WEAK[2004-07-11 02:39:56 +00:00]])

[21]
[SAMP(822)[with ESMTP/inet]] こんなのもある。
([[名無しさん]] [WEAK[2004-07-11 02:42:34 +00:00]])

[22]
[SAMP(822)[by [VAR[foo.example.org]] (AppleMailServer 38.0.2.6) id 668620 via NDR]]

こんなのがあった。
([[名無しさん]] [WEAK[2004-07-11 02:55:55 +00:00]])

[23]
[CODE(822)@en[[[WITH]]]] として [CODE(822)@en[[[MMS]]]]
が登録されました。
([[名無しさん]] [WEAK[2006-08-12 07:33:09 +00:00]])

[24]
太古の昔の: [CODE(822)@en[[[WITH]] [[TCP]]]]
([[名無しさん]])

[25]
[[Gmail]]: [CODE(822)@en[[[with]] [[HTTP]]]]

[31] [CODE(822)@en[[[with]] [[POP3]]]]

[29] [[IANA]] 登録簿に [[draft-ietf-eai-rfc5336bis-16]] を出典として
[CODE(822)@en[[[UTF8SMTP]]]], [CODE(822)@en[[[UTF8SMTPA]]]], 
[CODE(822)@en[[[UTF8SMTPS]]]], [CODE(822)@en[[[UTF8SMTPSA]]]],
[CODE(822)@en[[[UTF8LMTP]]]], [CODE(822)@en[[[UTF8LMTPA]]]], 
[CODE(822)@en[[[UTF8LMTPS]]]], [CODE(822)@en[[[UTF8LMTPSA]]]]
が追加されています。 [TIME[2011-12-10T11:03:15.00Z]]

** 注釈 comment について

RFC 2821 は慣習的に行われてきた、 comment 内に実ドメイン名・ IP address を
記録する方法を標準化しました。これに限らず Received: 領域の
注釈には有意義な情報が入れられていますから、注釈を取り除いて
解釈するのはよくないかもしれません。

しかし注釈は (RFC 2821/2822 で入る場所が限定されたとはいえ) RFC 822 以来
各要素間どこにでも入れられるので、構文解析 parse が面倒になります。
また、 RFC 2821 で標準化された注釈とそうでない注釈を
一目で見分ける方法はありません。

ですから、 Received: を解釈する実装としては、次のようなものが考えられます。

- 非構造化 unstructured 領域と同等に見て、構文解析しない
- 注釈内の情報を残すのは諦め、取り除いて解析する
- RFC 2821/2822 的に妥当 (で旧構文 obsolete syntax でない) 注釈はなんとか解析する
- 注釈は解析しないが、参考情報として残す

3番目の方法は旧構文の注釈 (例えば date-time 内の注釈) は取り除く必要が
あるので、なんだか面倒そうです。それから4番目の方法は
そこまでするならあと1歩で中身も解析出来る気が。

わけのわからんことぐたぐた述べてないで実装してみた方が
早いという説もありますが:-)

[6] [[MIME]] は [CODE[encoded-word]] を規定していますが、これを [CODE[Received:]]
欄の注釈内で使用してもいいのかは不明です。 (See [[encoded-word]>>12])

[7] [CODE[Received:]] 欄の日付の部分の後 (つまり一番最後)
には、その欄を加えたサーバーの現地の[[時間帯を表す文字列]]を注釈として入れておくと追跡の時に役に立つかもしれないのでイイとされています。

[[#comment]]

** env-from

- Received = rfc2822.Received FWS "env-from" FWS "(" host ")" [CFWS]

こんなのをつけてくる [[MTA]] がいるみたい。
例:

[PRE[
 Received: from localhost (daemon@localhost)
	by smtp.foo.example (8.9.3/8.9.3) with SMTP id KAA25477;
	Fri, 23 Feb 2001 10:42:36 +0900 (JST)
	env-from (from@bar.example)
]PRE]

[[#comment]]

** 参考

Received: 領域の数が多いと配送拒否されることがあるので、
mail-list などで Received: を X-Received: に置き換えることがある。
(あるいはそこでばっさり消されることもある。)

[9] [CODE[Received:]] 欄は長くなりがちなので、たいてい折畳まれています。
この時、2行目以降の行頭は [CODE(CHARNAME)[TAB]] になっているのが普通です。
また、名前‐値組の間や日付の途中で折畳むことはありません。

しかし、これはそうなっていることが多いだけで、 RFC 2822 や RFC 2821
を読んでもこれが強制されてはいないことが分かります。

[[#comment]]

** 関連する IANA 登録簿

- Mail parameters <http://www.iana.org/assignments/mail-parameters>
[[#comment]]

** 例

- [10] 以下の例は規格への適合性により分類していますが、この判断にはちょっと疑問もあります。
構文や本文規定を参考に振り分けなおす必要があるかもしれません。
[[#comment]]

*** RFC 2821 的に適当なもの

- Received: from foo3.example (foo4.example [127.0.0.1]) by foo2.example (Postfix) with ESMTP id E7F0824030; Sat, 16 Mar 2002 21:40:39 +0900 (JST)
- Received: (qmail 16842 invoked from network); 16 Mar 2002 21:41:54 +0900
- Received: (qmail 12928 invoked by uid 38); 16 Mar 2002 13:01:43 -0000
- Received: from foo8.example (mail@192.168.0.11) by foo9.example with SMTP; 16 Mar 2002 13:01:40 -0000
- Received: (from uucp@localhost) by foo9.example (8.9.1a/3.7W-u48) id OAA09787; Tue, 12 Mar 2002 14:12:37 +0900 (JST)
- Received: by foo10.example (8.9.1a/3.7W-hack) id OAA03107 for hoge-outgoing; Tue, 12 Mar 2002 14:08:04 +0900 (JST)
- Received: from foo.bar2.example ([61.198.253.195]) by foo.bar3.example (8.9.3 (PHNE_24848+JAGad82359)/8.8.6) with ESMTP id JAA17845; Sat, 9 Mar 2002 09:30:50 +0900 (JST)

[[#comment]]

*** RFC 2821 的に不適当だが RFC 2822 的に適当なもの

- Received: from unknown (HELO foo1.example) (192.168.0.1) by foo2.example with SMTP; 16 Mar 2002 21:41:54 +0900
- Received: from foo4.example (unknown [192.168.0.8]) by foo5.example (Postfix) with ESMTP id 48DB815007 for <bar@foo5.example>; Sat, 16 Mar 2002 21:04:21 +0800 (CST)
- Received: from bar by foo8.example with local (Exim 3.12 1 (Debian)) id 16mDoa-0004ep-00; Sat, 16 Mar 2002 07:01:40 -0600
- Received: from localhost ([127.0.0.1] helo=foo.bar1.example) by bar.bar1.example with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 16jUlY-0006UE-00; Fri, 08 Mar 2002 16:31:16 -0800

*** その他

- Received: from foo6.example [192.168.0.10] by foo7.example with smtp (Exim 3.12 1 (Debian)) id 16mDoZ-0004ec-00; Sat, 16 Mar 2002 07:01:39 -0600
- Received: from mailhost(192.9.200.18) by hogehoge via smap/slg/sizecheck/clearerr (V1.3) with ESMTP id fmala9603; Tue Mar 12 14:11:44 2002

[[#comment]]

** 参考文献

- [1] ''Fight spam on the Net!'' <http://ssss.jp/~trombik/email/index.html>
[CODE[Received:]] 欄の読み方を学習するのにいいでしょう。
[[#comment]]

** メモ

- [12] たまに、特に [[ML]] なんかで、おせっかいにも送信者にお宅の時計ずれてませんか? とか忠告する人いますね。 [CODE(822)[[[Date:]]]] 欄の日付が受信時刻からあまりに離れているからとか、 ML の他のメイルと番号と日付の関係が合わなかったりするのを根拠にそう言うんでしょうが。実際よく見てみると送信者の方の時計はおそらくあっていて、転送路の問題で遅れただけであることも実はよくあったりします。[WEAK[ML server が遅延の原因だったりすることもあったりします。]] わざわわざわざ忠告してみて知識をひけらかす暇があったら、 [CODE(822)[Received:]] 欄の読み方くらい勉強した方がいいですね(w
- [13] ほんとに、メイルが届くのに時間がかかって、しかも届くかどうか分からなかった時代は遠くに行ってしまったんですねぇ。それでも未だに遅延があるからには [CODE(822)[Received:]] 欄の存在意義も減らないとは思うんですけど、メイル配送路障害のことなんて考えもしない人が増えてるんだろうなあ。

* 歴史

** RFC 821 / RFC 822 時代

[FIG(quote)[ [43] [[RFC 821]] より抜粋

When the receiver-SMTP accepts a message either for relaying
            or for final delivery it inserts at the beginning of the
            mail data a time stamp line.  The time stamp line indicates
            the identity of the host that sent the message, and the
            identity of the host that received the message (and is
            inserting this time stamp), and the date and time the
            message was received.  Relayed messages will have multiple
            time stamp lines.

Example of Return Path and Received Time Stamps

Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>   
      Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
      Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
      Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
      Date: 27 Oct 81 15:01:01 PST                                
      From: JOE@ABC.ARPA                                          
      Subject: Improved Mailing System Installed                  
      To: SAM@JKL.ARPA                                            
                                    
      This is to inform you that ...

Example 8

The time stamp line and the return path line are formally
         defined as follows:

<return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>

<time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>

<from-domain> ::= "FROM" <SP> <domain> <SP>

<by-domain> ::= "BY" <SP> <domain> <SP>

<opt-info> ::= [<via>] [<with>] [<id>] [<for>]

<protocol> ::= The standard names for protocols are
                      registered with the Network Information Center.

<dd> ::= the one or two decimal integer day of the month in
                      the range 1 to 31.

<mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
                      "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"

<yy> ::= the two decimal integer year of the century in the
                      range 00 to 99.

<hh> ::= the two decimal integer hour of the day in the
                      range 00 to 24.

<mm> ::= the two decimal integer minute of the hour in the
                      range 00 to 59.

<ss> ::= the two decimal integer second of the minute in the
                      range 00 to 59.

<zone> ::= "UT" for Universal Time (the default) or other
                      time zone designator (as in [2]).

Time Stamp Line Example

Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT

Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
                   id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT

Example 10
]FIG]

[FIG(quote)[ [44] [[RFC 822]] の [[BNF]]

received    =  "Received"    ":"            ; one per relay
                       ["from" domain]           ; sending host
                       ["by"   domain]           ; receiving host
                       ["via"  atom]             ; physical path
                      *("with" atom)             ; link/mail protocol
                       ["id"   msg-id]           ; receiver msg id
                       ["for"  addr-spec]        ; initial form
                        ";"    date-time         ; time received
]FIG]

[FIG(quote)[ [45] [[RFC 822]] 4.3.2.  RECEIVED

A copy of this field is added by each transport  service  that
        relays the message.  The information in the field can be quite
        useful for tracing transport problems.

The names of the sending  and  receiving  hosts  and  time-of-
        receipt may be specified.  The "via" parameter may be used, to
        indicate what physical mechanism the message  was  sent  over,
        such  as  Arpanet or Phonenet, and the "with" parameter may be
        used to indicate the mail-,  or  connection-,  level  protocol
        that  was  used, such as the SMTP mail protocol, or X.25 tran-
        sport protocol.

Note:  Several "with" parameters may  be  included,  to  fully
               specify the set of protocols that were used.

Some transport services queue mail; the internal message iden-
        tifier that is assigned to the message may be noted, using the
        "id" parameter.  When the  sending  host  uses  a  destination
        address specification that the receiving host reinterprets, by
        expansion or transformation, the receiving host  may  wish  to
        record  the original specification, using the "for" parameter.
        For example, when a copy of mail is sent to the  member  of  a
        distribution  list,  this  parameter may be used to record the
        original address that was used to specify the list.

]FIG]

** USENET ニュースメッセージ

[51] 
[[USENET]] メッセージは [[RFC 822]] を基にしていますが、違いもいろいろあります。
[CODE[Received:]] 相当の機能も複数に分かれていろいろなものがありました。

--[[日付形式]]
---[[RFC850の日付形式]]
---[[asctime形式]]
--[[Date:領域]]
-[[電子ニュース]]
--[[RFC850]]
--[[RFC1036]]
--[[son-ofRFC1036]]
--[[draft-usefor-article]]
--[[NNTP]]

*** [CODE[Received:]]

[3] かつて Received: は記事を受け取った時間を表す領域として
USENET で使われていた。領域本体の値は USENET 形式の日付。
(See [[日付形式]]) RFC 850 ではすでに旧式とされ [[Date-Received:領域]] を使う
ことになっているが、 RFC 850 および RFC 1036 の例に挙がっている。

[4] 今ではもう使用されることはないでしょう。ただ、 [[INN]]
は現在の版でも [CODE[Received:]] 欄を持つメッセージの投稿は拒否します。
([CODE[Received:]] 欄のあるメッセージを中継する時は中継元で落としてから中継先に送っていた。)

*** [CODE[Date-Received:]]

[FIG(quote)[ [48] [[RFC 850]] 2.2.4  Date-Received

>
This line (formerly  "Received")  is
in  a  legal  USENET date format.  It records the date and
time that the article was  first  received  on  the  local
system.   If  this  line  is  present  in an article being
transmitted from one host to another, the  receiving  host
should  ignore  it  and  replace it with the current date.
Since this field is intended for local use only,  no  site
is  required  to support it.  However, no site should pass
this field on to another site unchanged.

この行 (元は「Received」(受信)) は妥当な USENET 日付形式です。
記事が最初に局地系統で受信した日時を記録します。
この行があるホストから他のホストに転送される記事に
ある時は、受信したホストはこれを無視し、現在時刻で置き換えます。
この領域は局地的に使うことだけを意図しているので、
どのサイトもこれに対応する必要はありません。しかし、
どのサイトもこの領域を他のサイトに変更せずに渡すべきではありません。
]FIG]

*** [CODE[Relay-Version:]]

[FIG(quote)[ [49] [[RFC 850]] 2.1.1  Relay-Version

This header line shows  the  version
of  the  program  responsible for the transmission of this
article over the immediate link, that is, the program that
is  relaying the article from the next site.  For example,
suppose site A sends an article to  site  B,  and  site  B
forwards  the  article  to  site  C.   The  message  being
transmitted from A to B would have a Relay-Version  header
identifying  the  program  running  on  A, and the message
transmitted from B to C would identify the program running
on  B.  This header can be used to interpret older headers
in an upward compatible way.  Relay-Version must always be
the  first  in  a message; thus, all articles meeting this
standard will begin with an upper case   "R".    No  other
restrictions are placed on the order of header lines.

この頭行は直接リンクでこの記事を転送する責任のあるプログラム、
すなわち記事を隣のサイトに中継するプログラムの版を示します。
例えば、サイト A が記事をサイト B に送り、サイト B が
記事をサイト C に転送するとします。 A から B に転送されたメッセージは
A で動いているプログラムを識別する Relay-Version 頭を
持っていて、 B から C に転送されたメッセージは
B で動いているプログラムを識別する頭を持っています。
この頭は上位互換のために古い頭を解釈するのに使うことが出来ます。
Relay-Version は常にメッセージの最初に無ければなりません。
ですから、この規格に合致する記事は全て大文字の「R」から
始まります。頭行の順序に関してこれ以外の制限はありません。

The line contains two  fields,  separated  by  semicolons.
The fields are the version and the full domain name of the
site.  The version should identify the system program used
(e.g.,   "B")   as  well  as  a version number and version
date.  For example, the header line might contain

行は2つの領域から成り、セミコロンで区切られます。領域は
版とサイトの完全ドメイン名です。版は系統プログラム (例えば「B」)
と版番号と版日付で識別するべきです。例えば、次の頭行を御覧下さい。

Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP

This header should not be passed on to  additional  sites.
A  relay  program,  when  passing  an  article  on, should
include only its own Relay-Version, not the  Relay-Version
of  some other site.  (For upward compatibility with older
software, if a Relay-Version is found in a header which is
not the first line, it should be assumed to be moved by an
older version of news and deleted.)

この頭は次のサイトには渡すべきではありません。中継プログラムは
記事を中継するとき、自分の Relay-Version だけを含め、
他のサイトの Relay-Version は含めません。 (古いソフトウェアとの
上位互換性のため、 Relay-Version は頭の最初の行以外に
現れるかもしれませんが、古い版のニュースが移動したと考えて
削除するべきです。)
]FIG]

*** [CODE[Posting-Version:]]

[FIG(quote)[ [50] [[RFC 850]] 2.1.2  Posting-Version

>
This   header   identifies   the
software  responsible  for  entering this message into the
network.  It has the same  format  as  Relay-Version.   It
will  normally  identify  the same site as the Message-ID,
unless the posting site is serving  as  a  gateway  for  a
message  that  already  contains a message ID generated by
mail.  (While it is permissible for a gateway  to  use  an
externally  generated message ID, the message ID should be
checked to ensure it conforms to this standard and to  RFC
822.)

この頭はネットワークに当該メッセージを注入した元のソフトウェア
を識別するものです。書式は Relay-Version と同じです。
これは通常 Message-ID のと同じサイトを識別します。
但し投稿サイトが関門でありメイルにより既に生成されたメッセージ ID を
持ったメッセージである場合を除きます。 (関門が外部で生成された
メッセージ ID を使っても構いませんが、メッセージ ID が
この規格と RFC 822 に適合するかは確認しておくべきです。)

]FIG]

** RFC 2821 / RFC 2822 時代

[FIG(quote)[ [46] [[RFC 2821]] 4.4 Trace Information 跡情報

When an SMTP server receives a message for delivery or further
processing, it MUST insert trace ("time stamp" or "Received")
information at the beginning of the message content, as discussed in
section 4.1.1.4.

SMTP サーバーがメッセイジを配送あるいは更なる処理のために
受け取った時には、跡 (「時間印」あるいは「受信した」) 情報を
メッセイジ内容のはじめに、第4.1.1.4節で説明したように
挿入''しなければなりません''。

This line MUST be structured as follows:

この行は次のように構成''しなければなりません''。

-The FROM field, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.
-FROM 領域。これは SMTP 環境ではつけ''なければならず''、(1) EHLO 命令で知らされた原ホストの名前 (2) 原ホストの IP アドレスを含むアドレス・リテラルの両者を含める''べき''です。
-The ID field MAY contain an "@" as suggested in RFC 822, but this is not required.
-ID 領域は RFC 822 で提案されているように「@」から成っていても''よい''ですが、惟は必要ではありません。
-The FOR field MAY contain a list of <path> entries when multiple RCPT commands have been given.  This may raise some security issues and is usually not desirable; see section 7.2.
-FOR 領域は複数の RCPT 命令が与えられている時に <path> 項目の表から成っていても''よい''です。これは保安問題を起こしかねないし通常望ましくありません。第7.2節を参照。

An Internet mail program MUST NOT change a Received: line that was
previously added to the message header.  SMTP servers MUST prepend
Received lines to messages; they MUST NOT change the order of
existing lines or insert Received lines in any other location.

Internet メイル・プログラムは前にメッセイジ・ヘッダーに追加された Received: 行
を変更しては''いけません''。 SMTP サーバーは Received 行を
メッセイジのはじめに加え''なければなりません''。
既存の行の順番を変えたり Received 行を他の場所に入れたりしては''いけません''。

As the Internet grows, comparability of Received fields is important
for detecting problems, especially slow relays.  SMTP servers that
create Received fields SHOULD use explicit offsets in the dates
(e.g., -0800), rather than time zone names of any type.  Local time
(with an offset) is preferred to UT when feasible.  This formulation
allows slightly more information about local circumstances to be
specified.  If UT is needed, the receiver need merely do some simple
arithmetic to convert the values.  Use of UT loses information about
the time zone-location of the server.  If it is desired to supply a
time zone name, it SHOULD be included in a comment.

Internet の成長に従って、 Received 領域の比較は問題、特に
配送遅延の特定に重要となりました。 Received 領域を作る SMTP サーバーは
いかなる種の時間帯名よりも日付の明示的な差 (例えば -0800) を使う''べき''です。
(差つき)現地時間は UT (協定世界時) より利用価値があります。
この方法なら指定される地域事情について幾分多くの情報を伝えられます。
UT が必要なら、受信者が単に値を直す計算をすればいいだけです。
UT を使うとサーバーの時間帯位置についての情報が失われます。
時間帯名を示すことが必要なら、注釈に入れる''べき''です。

(中(Return-Path:関連)略)

The time stamp line and the return path line are formally defined as
follows:

時間印行及び復帰経路行は正式には次のように定義します。

Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>

Time-stamp-line = "Received:" FWS Stamp <CRLF>

Stamp = From-domain By-domain Opt-info ";"  FWS date-time

; where "date-time" is as defined in [32]
      ; but the "obs-" forms, especially two-digit
      ; years, are prohibited in SMTP and MUST NOT be used.

; 「date-time」は[[RFC2822の日付形式]]で定義されたものですが、
「obs-」形式、特に2桁年は SMTP では禁止し、使用しては''なりません''。

From-domain = "FROM" FWS Extended-Domain CFWS

By-domain = "BY" FWS Extended-Domain CFWS

Extended-Domain = Domain /
           ( Domain FWS "(" TCP-info ")" ) /
           ( Address-literal FWS "(" TCP-info ")" )

TCP-info = Address-literal / ( Domain FWS Address-literal )
      ; Information derived by server from TCP connection
      ; not client EHLO.

; サーバーが、クライアントの EHLO ではなく TCP 接続から得た情報

Opt-info = [Via] [With] [ID] [For]

Via = "VIA" FWS Link CFWS

With = "WITH" FWS Protocol CFWS

ID = "ID" FWS String / msg-id CFWS

For = "FOR" FWS 1*( Path / Mailbox ) CFWS

Link = "TCP" / Addtl-Link
  Addtl-Link = Atom
      ; Additional standard names for links are registered with the
         ; Internet Assigned Numbers Authority (IANA).  "Via" is
         ; primarily of value with non-Internet transports.  SMTP
         ; servers SHOULD NOT use unregistered names.

; 追加のリンクの標準名称は Internet 登録番号事務局 (IANA) で登録
されます。「Via」は主として非 Internet 配送路の値です。
SMTP サーバーは非登録名を使用''すべきでありません''。

訳注: 2002年3月現在、「UUCP」が登録されています。

Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
  Attdl-Protocol = Atom
      ; Additional standard names for protocols are registered with the
         ; Internet Assigned Numbers Authority (IANA).  SMTP servers
         ; SHOULD NOT use unregistered names.

; 追加のプロトコルの標準名は Internet 登録番号事務局 (IANA) で登録
されます。 SMTP サーバーは非登録名を使用''すべきでありません''。

訳注: 2002年3月現在、追加の登録はありません。

]FIG]

[FIG(quote)[ [47] [[RFC 2821]] のそのほかの部分にある BNF

address-literal = "[" IPv4-address-literal /
                            IPv6-address-literal /
                            General-address-literal "]"
            ; See section 4.1.3

Atom = 1*atext

String = Atom / Quoted-string

IPv4-address-literal = Snum 3("." Snum)
      IPv6-address-literal = "IPv6:" IPv6-addr
      General-address-literal = Standardized-tag ":" 1*dcontent
      Standardized-tag = Ldh-str
            ; MUST be specified in a standards-track RFC
            ; and registered with IANA

Snum = 1*3DIGIT  ; representing a decimal integer
            ; value in the range 0 through 255
      Let-dig = ALPHA / DIGIT
      Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig

IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
      IPv6-hex  = 1*4HEXDIG
      IPv6-full = IPv6-hex 7(":" IPv6-hex)
      IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
                 IPv6-hex)]
            ; The "::" represents at least 2 16-bit groups of zeros
            ; No more than 6 groups in addition to the "::" may be
            ; present
      IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
      IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
                   [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
            ; The "::" represents at least 2 16-bit groups of zeros
            ; No more than 4 groups in addition to the "::" and
            ; IPv4-address-literal may be present

Path = "<" [ A-d-l ":" ] Mailbox ">"
      Mailbox = Local-part "@" Domain

]FIG]

[FIG(quote)[ [39] [[RFC 2822]] 3.6.7. Trace fields 追跡欄

>The trace fields are a group of header fields consisting of an
optional "Return-Path:" field, and one or more "Received:" fields.
The "Return-Path:" header field contains a pair of angle brackets
that enclose an optional addr-spec.  The "Received:" field contains a
(possibly empty) list of name/value pairs followed by a semicolon and
a date-time specification.  The first item of the name/value pair is
defined by item-name, and the second item is either an addr-spec, an
atom, a domain, or a msg-id.  Further restrictions may be applied to
the syntax of the trace fields by standards that provide for their
use, such as [RFC2821].

追跡欄は省略可能な "Return-Path:" 欄と1つ以上の "Received:"
欄からなる頭欄の集団です。 "Return-Path:" 頭欄は angle
括弧の組とそれに囲まれた省略可能な [[addr-spec]] で構成されます。
"Received:" 欄は (空かも知れない) 名前/値の組の表にセミコロンと
[[date-time]] 記述が続くものです。名前/値組の最初の項目は
item-name で定義され、2番目の項目は addr-spec, [[atom]],
[[domain]], または [[msg-id]] で定義されます。追跡欄の構文はこれを使う
RFC 2821 のような規格により更なる制限が加えられるかもしれません。

-trace           =       [return]                        1*received
-return          =       "Return-Path:" path CRLF
-path            =       ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) /                        obs-path
-received        =       "Received:" name-val-list ";" date-time CRLF
-name-val-list   =       [CFWS] [name-val-pair *(CFWS name-val-pair)]
-name-val-pair   =       item-name CFWS item-value
-item-name       =       ALPHA *(["-"] (ALPHA / DIGIT))
-item-value      =       addr-spec / atom / domain / msg-id

>A full discussion of the Internet mail use of trace fields is
contained in [RFC2821].  For the purposes of this standard, the trace
fields are strictly informational, and any formal interpretation of
them is outside of the scope of this document.

追跡欄の Internet メイルでの仕様についての完全な議論は
RFC 2821 に含まれています。この規格の目的では、追跡情報は完全に情報提供的なもので、これらの正式な解釈はこの文書の適用範囲外とします。
]FIG]

[FIG(quote)[ [40] [[RFC 2822]] 4.5.7. Obsolete trace fields

>The obs-return and obs-received are again given here as template
definitions, just as return and received are in section 3.  Their
full syntax is given in [RFC2821].

-obs-return      =       "Return-Path" *WSP ":" path CRLF
-obs-received    =       "Received" *WSP ":" name-val-list CRLF
-obs-path        =       obs-route-addr
]FIG]

[26]
[[RFC 5335]] は、 [CODE(822)@en[[[For]]]] [[欄]]における [[UTF-8]]
を含む[[電子メイル番地]] ([CODE(ABNF)@en[[[utf8-addr-spec]]]]) の使用を認めています。
[[RFC 5335]] はこれを [[uFor]] 構文と呼んでいます。

;; [[RFC 5335]] 4.5

[28] [CITE[FGA: Some of what is said about "qmail" is wrong]] ([TIME[2004-12-08 10:45:51 +09:00]] 版) <http://homepages.tesco.net/J.deBoynePollard/FGA/qmail-myths-dispelled.html#MythAboutQQReceivedHeaders>

[27] [CITE@ja[qmailのReceivedヘッダがRFC違反に? « 雑多なブログ]] ([TIME[2008-12-29 20:46:17 +09:00]] 版) <http://tec.jpn.ph/wordpress/?p=883>

[30] [CITE@en[RFC 6729 - Indicating Email Handling States in Trace Fields]]
( ([TIME[2012-09-08 08:24:48 +09:00]] 版))
<http://tools.ietf.org/html/rfc6729>

[32] 
[PRE(822 example code)[
Received: from 291235132082.apps.googleusercontent.com
	named unknown
	by gmailapi.google.com
	with HTTPREST;
	Thu, 24 Jul 2014 20:14:57 -0700
]PRE]

;; [[Gmail API]] から送信したメール

[8] 
[PRE(822 code)[
Received: by filter-171.sjc1.sendgrid.net with SMTP id filter-171.16166.544FBEEA19
        2014-10-28 16:06:04.814281002 +0000 UTC
]PRE]

[33] [CITE@ja[Received: format of various SMTP Mail Transfer Agents]]
( ([TIME[2012-01-30 18:26:40 +09:00]] 版))
<http://vega.sra-tohoku.co.jp/~kabe/vsd/mail/received.html>

[FIG(quote)[
[FIGCAPTION[
[34] [CITE@en[RFC 1428 - Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME]]
([TIME[2015-07-26 14:25:37 +09:00]] 版)
<https://tools.ietf.org/html/rfc1428>
]FIGCAPTION]

> 
>    Trace information should be added to the document with a convert
>    clause: "rfc822-to-8bit", "rfc822-to-base-64" or "rfc822-to-quoted-
>    printable" e.g.,
>    Received: from dbc.mtview.ca.us by dbc.mtview.ca.us
>              convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700

]FIG]

[FIG(quote)[
[FIGCAPTION[
[35] [CITE@en[old-delphi-codes/headers.txt at master · maerlyn/old-delphi-codes]]
([TIME[2016-01-15 19:33:13 +09:00]] 版)
<https://github.com/maerlyn/old-delphi-codes/blob/master/POPper/GUI%20no2/headers.txt>
]FIGCAPTION]

> 
> Received: from dial-3-236.emitel.hu(194.149.57.236) by brutus via csmap (V6.0)
> 	id srcAAAb2aGGy; Tue, 6 Apr 04 17:55:45 +0200

]FIG]

[FIG(quote)[
[FIGCAPTION[
[41] [CITE[email - POP3 RETR Command Missing +OK Response - Stack Overflow]]
([TIME[2020-11-27T02:42:25.000Z]])
<https://stackoverflow.com/questions/27686554/pop3-retr-command-missing-ok-response>
]FIGCAPTION]

> Received: from x ('''['''x.x.60.10''']''') by x.net with MailEnab
> le ESMTP; Sun, 28 Dec 2014 11:30:16 +0200

]FIG]

[42] [CITE@en[Previously Unpublished Emails of Satoshi Nakamoto Present New Puzzle- CoinDesk]], [TIME[2020-11-27T02:42:58.000Z]] <https://www.coindesk.com/satoshi-nakamoto-hal-finney-emails>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)