[2] Received:
欄は、普通電子メイルで使って、配送の記録が行われる欄です。
他に、電子ニュースでもかつてはつかわれていました。
[3] 配送の各段階の数だけどんどん追加されていきます。 メイルがどのような経路で配送されたのかやどのサーバーが不調なのかなどの追跡に使用出来ます。 (現在では途中経路を数 hop も経ないで直接サイトからサイトに配送されるのが普通ですし、途中の経過サイトの不調のための遅延もかなり稀ですが、昔はよくあることでした。)
[5] RFC2822 は一般的な Received:
欄の構文を規定しています。
RFC2821 (SMTP) は、 SMTP サーバーが Received:
欄に記録すること及びその書式を規定しています。 RFC 2821 の構文は
RFC 2822 のものより具体的・厳格になっています。
RFC 2822, RFC 2821 の旧版である RFC822, RFC821 についても同じような関係がありますが、 2822/2821 程はっきり分化してはいません。
昔は結構すきなよーな値を入れてたらしい。
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] SMTP
と ESMTP
の値の意味は 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
です。 A
は SMTP AUTH, S
は TLS, LMTP
は LMTP です。 ESMTP
は ESMTP 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)
[29] IANA 登録簿に draft-ietf-eai-rfc5336bis-16 を出典として
UTF8SMTP
, UTF8SMTPA
,
UTF8SMTPS
, UTF8SMTPSA
,
UTF8LMTP
, UTF8LMTPA
,
UTF8LMTPS
, UTF8LMTPSA
が追加されています。
RFC 2821 は慣習的に行われてきた、 comment 内に実ドメイン名・ IP address を 記録する方法を標準化しました。これに限らず Received: 領域の 注釈には有意義な情報が入れられていますから、注釈を取り除いて 解釈するのはよくないかもしれません。
しかし注釈は (RFC 2821/2822 で入る場所が限定されたとはいえ) RFC 822 以来 各要素間どこにでも入れられるので、構文解析 parse が面倒になります。 また、 RFC 2821 で標準化された注釈とそうでない注釈を 一目で見分ける方法はありません。
ですから、 Received: を解釈する実装としては、次のようなものが考えられます。
3番目の方法は旧構文の注釈 (例えば date-time 内の注釈) は取り除く必要が あるので、なんだか面倒そうです。それから4番目の方法は そこまでするならあと1歩で中身も解析出来る気が。
わけのわからんことぐたぐた述べてないで実装してみた方が 早いという説もありますが:-)
[6] MIME は encoded-word
を規定していますが、これを Received:
欄の注釈内で使用してもいいのかは不明です。 (See encoded-word (>>12))
[7] Received:
欄の日付の部分の後 (つまり一番最後)
には、その欄を加えたサーバーの現地の時間帯を表す文字列を注釈として入れておくと追跡の時に役に立つかもしれないのでイイとされています。
こんなのをつけてくる 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 を読んでもこれが強制されてはいないことが分かります。
Received:
欄の読み方を学習するのにいいでしょう。
Date:
欄の日付が受信時刻からあまりに離れているからとか、 ML の他のメイルと番号と日付の関係が合わなかったりするのを根拠にそう言うんでしょうが。実際よく見てみると送信者の方の時計はおそらくあっていて、転送路の問題で遅れただけであることも実はよくあったりします。ML server が遅延の原因だったりすることもあったりします。 わざわわざわざ忠告してみて知識をひけらかす暇があったら、 Received:
欄の読み方くらい勉強した方がいいですね(wReceived:
欄の存在意義も減らないとは思うんですけど、メイル配送路障害のことなんて考えもしない人が増えてるんだろうなあ。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
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
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.
[3] かつて Received: は記事を受け取った時間を表す領域として USENET で使われていた。領域本体の値は USENET 形式の日付。 (See 日付形式) RFC 850 ではすでに旧式とされ Date-Received:領域 を使う ことになっているが、 RFC 850 および RFC 1036 の例に挙がっている。
[4] 今ではもう使用されることはないでしょう。ただ、 INN
は現在の版でも Received:
欄を持つメッセージの投稿は拒否します。
(Received:
欄のあるメッセージを中継する時は中継元で落としてから中継先に送っていた。)
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:
この行は次のように構成しなければなりません。
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月現在、追加の登録はありません。
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
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 のような規格により更なる制限が加えられるかもしれません。
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 に含まれています。この規格の目的では、追跡情報は完全に情報提供的なもので、これらの正式な解釈はこの文書の適用範囲外とします。
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].
[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
Received: from 291235132082.apps.googleusercontent.com named unknown by gmailapi.google.com with HTTPREST; Thu, 24 Jul 2014 20:14:57 -0700
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
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
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
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