メールヘッダと送信クライアント

2008/10/06
2009/02/22 追加

RFC2821 の HELO ホスト

RFC2821 はメールの送受信のプロトコルを定めている。これによるとメールを送信しようとするクライアントはサーバに対して

HELO ホスト

あるいは

EHLO ホスト

の形式のメッセージをサーバに送る必要がある。ここに「ホスト」は、もしもクライアントが DNS に登録されていれば、そのクライアントの FQDN でなければならない。登録されていなければホスト部分は

[123.255.37.2]

のようにクライアントの IP アドレスを括弧([ ])で括るべきである。

僕が受け取ったメールから、いくつかの例を挙げる。

メールのヘッダにはクライアントが名乗った「ホスト」部分の記録が残っている。例えば

Received: from userg502.nifty.com ([202.248.238.82]) by ar

これは IP アドレスが 202.248.238.82 のクライアントからのメールであり、「userg502.nifty.com」はクライアントが名乗った「ホスト」である。userg502.nifty.com の IP アドレスが実際に 202.248.238.82 である事は nslookup のようなツールで判明する。

-bash$ nslookup userg502.nifty.com
Server:		210.147.240.193
Address:	210.147.240.193#53

Non-authoritative answer:
Name:	userg502.nifty.com
Address: 202.248.238.82

amazon や google のように巨大なシステムから送信されるメールは幾分複雑である。例えば google のメールは

Received: from qb-out-1314.google.com ([72.14.204.170]) by ar

のようなホストを名乗っている。しかし

-bash$ nslookup qb-out-1314.google.com
Server:		202.225.94.247
Address:	202.225.94.247#53

Non-authoritative answer:
Name:	qb-out-1314.google.com
Address: 72.14.204.169
Name:	qb-out-1314.google.com
Address: 72.14.204.170
Name:	qb-out-1314.google.com
Address: 72.14.204.171
Name:	qb-out-1314.google.com
Address: 72.14.204.172
Name:	qb-out-1314.google.com
Address: 72.14.204.173
Name:	qb-out-1314.google.com
Address: 72.14.204.174
Name:	qb-out-1314.google.com
Address: 72.14.204.175
Name:	qb-out-1314.google.com
Address: 72.14.204.168

で分かるとおり、「qb-out-1314.google.com」には 8 個の IP が割り付けられている。実際に送信したクライアントはその内の一つ 72.14.204.170 である。amazon や biglobe についても同様に、メール送信に使われるクライアントの IP は「ホスト」の IP の中に含まれる。

以下に僕が受け取ったメールで、この規則に従っているサイトは

google.com, amazon.com, biglobe.ne.jp, apple.com, nifty.com, commufa.jp, softbank.ne.jp

などである。現在では小さなサイト、例えば小さなネットショップなどでも RFC2821 のこのルールが守られつつある。

アウトローたち

docomo

しかしながら日本を代表する通信業者である docomo はどうか?

「RFC2821 docomo」でググってみれば分かるとおり、docomo への非難が渦巻いている。これらの非難の殆どは docomo のユーザ名規則*に集中している。しかし、ここで取り上げた「ホスト」の扱いもまた問題なのだ。

注 *: RFC2821 では許されないユーザ名(「..」を含んだり、「.」を末尾に含むもの)を docomo はユーザ名として許可している。

docomo からのメールは次のようになっている。

Received: from docomo.ne.jp ([203.138.203.197]) by ar

nslookup で調べると

-bash$ nslookup docomo.ne.jp
Server:		202.225.94.247
Address:	202.225.94.247#53

Non-authoritative answer:
*** Can't find docomo.ne.jp: No answer

つまり「ホスト」部の「docomo.ne.jp」は形式的なもので IP アドレスが割り付けられていないのだ。このような IP アドレスを引けない「ホスト」を名乗っているのは、架空のホストを名乗るスパマーや技術力のない極少数の小さなネットショップを別にすれば、僕の知る限り docomo だけである。

EZweb, mixi, asahi-net, ...

docomo ほど酷くはないが、EZweb, mixi, asahi-net は共通の問題を抱えている。例えば EZweb からのメールは

Received: from ezweb.ne.jp ([59.135.39.213]) by ar

であるが

-bash$ nslookup ezweb.ne.jp
Server:		202.225.94.247
Address:	202.225.94.247#53

Non-authoritative answer:
Name:	ezweb.ne.jp
Address: 222.15.69.195

で分かるとおり、名乗られた「ホスト」は実際のクライアントと一致しない。スパマーはしばしば適当なホストを名乗ってメールを送信するが、それと同じ特徴を備えているのである。

混乱をもたらす SPF

2009/02/22

息子の携帯電話(ezweb.ne.jp)へ出した重要なメールがゴミ箱に入ったらしい。そのために重要な場面で意思疎通が混乱した。これまではチャンと通信できていたのに。この問題が SPF と関係があるのかどうかは不明である。でもこの事が契機になって EZweb が SPF をスパムメール対策に採用している事に気付いた。

前節の「アウトローたち」で docomo と EZweb を槍玉に挙げたが、彼らは全く自己流でやっているわけではないようだ。どうやら彼らは SPF(Sender Policy Framework) の積極的な推進者らしい。

SPF の何であるかは Web 上に多くの解説が乗っているので改めて解説しない。ただ僕が強調したいのは既存の SMTP のスタンダードである RFC2821 と相容れないことだ。SPF の推進者たちは SPF は RFC 化されている(RFC4408)と言うが、RFC4408 を見れば分かるように、この RFC は未だに Experimental な位置づけである。

僕の経験ではスパム対策には「 HELO ホスト」(HELO や EHLO で名乗られたホスト)の正当性を確認するのが極めて有効である。この正当性が確認できるように「 HELO ホスト」は送信クライアントを識別できる FQDN でなくてはならないと RFC2821 は述べている。正当性の確認には名乗られた「 HELO ホスト」の IP アドレスを DNS サーバに問い合わせればよい。(DNS サーバはこの仕組みを既に持っている。) メールの受け手(受信サーバー)が信じることが出来るのは送信クライアントの IP と(信頼できる) DNS サーバからの情報だけだから... (もちろん公開鍵暗号などの手段はあるが、日常的な使用にかんしては大袈裟である)

SPF の推進者たちは、既存の方法では送信クライアントの正当性が確認できないかのように述べている。例えば docomo の解説は

送信ドメイン認証（Sender ID/SPF）とは、メールが正当なメールサーバから送信されたものか否かを判断する認証技術です。

iモードセンタが送信ドメイン認証をする際は、送信元のIPアドレスと、DNSサーバに公開された送信用メールサーバのIPアドレスとを比較し、合致した場合にのみメール受信し、不一致の場合や、当該IPアドレスがDNSサーバに存在しないなど、整合性がとれない場合には受信しません。
...
SPF（TXT）レコードの確認には、メールヘッダのFROMフィールドを使用します。なお、メールヘッダのFROMフィールドが存在しない場合はエンベロープFROMを使用します。

と述べており、また au も

送信ドメイン認証SPFレコードとは、メールを送信するサーバの情報をDNSサーバ上で公開し、送信されたメールのドメイン名とDNSサーバの SPFレコードとの整合性を受信サーバ側で確認することで、そのメールが正当なメールサーバから送信されたものかを認証する技術です。これにより、正当なメールサーバから送信されたメールと「なりすましメール」とを判別することが可能となります。その為には送信されているメールのドメイン (エンベロープFrom) と送信IPアドレスの関連をSPFレコードに記述していただく必要がございます。

と述べているが、僕は全く同じ事を(但し「From」ではなく HELO ホストを基に) DNS の SPF 情報を使わないで(RFC2821 の枠内で)行っている*。SPF に移行しなければ出来ないと言うのは真っ赤な嘘である。もっとも docomo も EZweb も RFC2821 を守らないので例外扱いにせざるを得ないが...

注 *: http://plan9.aichi-u.ac.jp/spamfilter/

SPF に関する参考 URL

Sender Policy Framework
http://ja.wikipedia.org/wiki/Sender_Policy_Framework
送信ドメイン認証（Sender ID／SPF）について
http://www.nttdocomo.co.jp/service/mail/imode_mail/notice/sender_id/
送信ドメイン認証SPFレコードについて
http://www.au.kddi.com/service/email/support/chui/spf_record.html
Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
http://www.ietf.org/rfc/rfc4408.txt
インターネットIT技術者のページ
http://it-arch.jugem.jp/?eid=75
SPF is harmful. Adopt it.
http://homepages.tesco.net/J.deBoynePollard/FGA/smtp-spf-is-harmful.html
Sender IDはスパム対策の切り札となるか!?
http://www.atmarkit.co.jp/fsecurity/rensai/trend01/trend01.html

docomo と EZweb からのメールの IP

ついでに僕が欲しかった情報が載っているページを見つけたので載せておく。

iモードセンタのIPアドレス帯域
http://www.nttdocomo.co.jp/service/imode/make/content/ip/
EZwebメールサーバIPアドレス情報
http://www.au.kddi.com/service/email/support/chui/shiyo/iip_ichiran.html

RFC5321

2009/03/07

ネットサーフィンしていると、RFC2821 が RFC5321 として改訂されている。発行は October 2008 となっているので半年前だ。
RFC2821 では HELO ホストについて

4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)

   These commands are used to identify the SMTP client to the SMTP
   server.  The argument field contains the fully-qualified domain name
   of the SMTP client if one is available.  In situations in which the
   SMTP client system does not have a meaningful domain name ...

とは書かれている。 HELO ホストは送信クライアントの FQDN だと述べているが、DNS との関係については(常識的には当然 DNS に登録されていると解釈されるが)明示的には語られていなかった。この点に関して RFC5321 は次のように駄目を押している。

2.3.5.  Domain Names
...
   o  The domain name given in the EHLO command MUST be either a primary
      host name (a domain name that resolves to an address RR) or, if
      the host has no name, an address literal, as described in
      Section 4.1.3 and discussed further in the EHLO discussion of
      Section 4.1.4.

つまり、送信クライアントが名乗る FQDN は DNS サーバにその IP アドレスが登録されている必要がある。つまり docomo 方式は完全にアウトである。別 FQDN を名乗っている EZweb 方式も無理がある。許されるのは Google 方式までである。

さて RFC5321 が SPF に関して述べているのは次の下りだけである。

   This specification does not deal with the verification of return
   paths for use in delivery notifications.  Recent work, such as that
   on SPF [29] and DKIM [30] [31], has been done to provide ways to
   ascertain that an address is valid or belongs to the person who
   actually sent the message.  A server MAY attempt to verify the return
   path before using its address for delivery notifications, but methods
   of doing so are not defined here nor is any particular method
   recommended at this time.

サーバは、「配送出来ませんでした」の通知を行う際に SPF を確認のために使ってもよいが、推奨されないよと言う立場である。

docomo にせよ、EZweb にせよ、NTT と KDDI の殿様体質が染み付いているように僕には見える。彼らがもっと謙虚になるためにも「Softbank に乗り換えよう!」とつい言いたくなってくるのだ。

Simple Mail Transfer Protocol
http://www.ietf.org/rfc/rfc5321.txt