[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: 欄の存在意義も減らないとは思うんですけど、メイル配送路障害のことなんて考えもしない人が増えてるんだろうなあ。[3] かつて Received: は記事を受け取った時間を表す領域として USENET で使われていた。領域本体の値は USENET 形式の日付。 (See 日付形式) RFC 850 ではすでに旧式とされ Date-Received:領域 を使う ことになっているが、 RFC 850 および RFC 1036 の例に挙がっている。
[4] 今ではもう使用されることはないでしょう。ただ、 INN
は現在の版でも Received: 欄を持つメッセージの投稿は拒否します。
(Received: 欄のあるメッセージを中継する時は中継元で落としてから中継先に送っていた。)
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