Received

Received: ヘッダー (インターネットメール)

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

目次

  1. 仕様書
  2. 電子メイルにおける Received: 欄
    1. 注釈 comment について
    2. env-from
    3. 参考
    4. 関連する IANA 登録簿
      1. RFC 2821 的に適当なもの
      2. RFC 2821 的に不適当だが RFC 2822 的に適当なもの
      3. その他
    5. 参考文献
    6. メモ
  3. 歴史
    1. RFC 821 / RFC 822 時代
    2. USENET ニュースメッセージ
    3. RFC 2821 / RFC 2822 時代
    4. §

仕様書#

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

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

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

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

#

  • 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" BITNETSMTP?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[25] Gmail: with HTTP

[31] with POP3

[29] IANA 登録簿に draft-ietf-eai-rfc5336bis-16 を出典として UTF8SMTP, UTF8SMTPA, UTF8SMTPS, UTF8SMTPSA, UTF8LMTP, UTF8LMTPA, UTF8LMTPS, UTF8LMTPSA が追加されています。

注釈 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] MIMEencoded-word を規定していますが、これを Received: 欄の注釈内で使用してもいいのかは不明です。 (See encoded-word (>>12))

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

env-from#

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

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

 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)

参考#

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

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

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

関連する IANA 登録簿#

#

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

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)

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

参考文献#

メモ#

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

歴史#

RFC 821 / RFC 822 時代#

[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>
            <stamp> ::= <from-domain> <by-domain> <opt-info> ";"
                      <daytime>
            <from-domain> ::= "FROM" <SP> <domain> <SP>
            <by-domain> ::= "BY" <SP> <domain> <SP>
            <opt-info> ::= [<via>] [<with>] [<id>] [<for>]
            <via> ::= "VIA" <SP> <link> <SP>
            <with> ::= "WITH" <SP> <protocol> <SP>
            <id> ::= "ID" <SP> <string> <SP>
            <for> ::= "FOR" <SP> <path> <SP>
            <link> ::= The standard names for links are registered with
                      the Network Information Center.
            <protocol> ::= The standard names for protocols are
                      registered with the Network Information Center.
            <daytime> ::= <SP> <date> <SP> <time>
            <date> ::= <dd> <SP> <mon> <SP> <yy>
            <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
            <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
[44] RFC 822BNF
     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
[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.

USENET ニュースメッセージ#

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

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

RFC 2821 / RFC 2822 時代#

[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月現在、追加の登録はありません。

[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
[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 に含まれています。この規格の目的では、追跡情報は完全に情報提供的なもので、これらの正式な解釈はこの文書の適用範囲外とします。

[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

#

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

[28] FGA: Some of what is said about "qmail" is wrong ( 版) http://homepages.tesco.net/J.deBoynePollard/FGA/qmail-myths-dispelled.html#MythAboutQQReceivedHeaders

[27] qmailのReceivedヘッダがRFC違反に? « 雑多なブログ ( 版) http://tec.jpn.ph/wordpress/?p=883

[30] RFC 6729 - Indicating Email Handling States in Trace Fields ( ( 版)) http://tools.ietf.org/html/rfc6729

[32]

Received: from 291235132082.apps.googleusercontent.com
	named unknown
	by gmailapi.google.com
	with HTTPREST;
	Thu, 24 Jul 2014 20:14:57 -0700

Gmail API から送信したメール

[8]

Received: by filter-171.sjc1.sendgrid.net with SMTP id filter-171.16166.544FBEEA19
        2014-10-28 16:06:04.814281002 +0000 UTC

[33] Received: format of various SMTP Mail Transfer Agents ( ( 版)) http://vega.sra-tohoku.co.jp/~kabe/vsd/mail/received.html

[34] RFC 1428 - Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME ( 版) https://tools.ietf.org/html/rfc1428

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

[35] old-delphi-codes/headers.txt at master · maerlyn/old-delphi-codes ( 版) https://github.com/maerlyn/old-delphi-codes/blob/master/POPper/GUI%20no2/headers.txt

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

[41] email - POP3 RETR Command Missing +OK Response - Stack Overflow () https://stackoverflow.com/questions/27686554/pop3-retr-command-missing-ok-response

Received: from x ([x.x.60.10]) by x.net with MailEnab

le ESMTP; Sun, 28 Dec 2014 11:30:16 +0200

[42] Previously Unpublished Emails of Satoshi Nakamoto Present New Puzzle- CoinDesk, https://www.coindesk.com/satoshi-nakamoto-hal-finney-emails