「よくわからんけど動いてる」から一歩進むためのメール設定の盗み方

普段から当たり前のように使っているEmailはインターネット黎明期より伝わる伝説のコミュニケィションツールでもあります. しかし歴史が長くかつ良くも悪くも使い倒されてきたが故に, 継ぎ足し継ぎ足し受け継がれてきた秘伝のスープが如きテイストを醸し出している事実も否定出来ません.
そして本記事はここ最近メール案件にどっぷり浸かっているうち秘伝のスープの味わい方がなんとなく見えてきた気がするのでそれを共有… というか, 他の会社のメール設定を見てニヤニヤする方法を書くだけの記事です. 申し遅れました, 執筆はうどんエンジニアのHashです.

さて, 以下は僕もここ数日で知った知識ばかりですので, 間違いを発見し, かつそれを知らせるだけの親切心を持ち合わせている方はご連絡いただけると嬉しいです.


【メールヘッダーを見てニヤニヤする】

まずは生メールデータの確認方法から. Gmailなら以下の場所から飛べます. 他は知りません.

Gmailでは”Show Original”を選択



別tabでテキストが開きます. 「項目: 値」という配置でメールヘッダーがいろいろと見えますね.


Delivered-Toは要は宛先. From, To, Subjectはお馴染みなので省略するとして, いくつか興味深い項目があります.


Return-Path: xxxxxxxxxx+yy=zzz.pbz@postmaster.twitter.com


Return-Pathは, 宛先への配信がエラーとなったとき, 「エラーになったよー」とお知らせする宛先を定義しています(幸いにしてこうして無事メールが届き今読んでいるわけですが). twitter.com ドメインのpostmasterというホストに対し, 何やら動的っぽい値をユーザ名としたアドレスが定義されています.
これは, メール配信エラーが起こった時にそれを自社サーバに通知してもらって, 「ユーザーID XXX番の人への配信でエラーが起きたよ」と把握できるようになっているのだと思います. 謎の値はTwitterのサーバでユーザを特定するためのkeyになっているのでしょう.

TwitterやらLinkedIn, FacebookはReturn-Pathに動的な値を割り当てておりメール配信エラーをトラッキングしていることがわかります. 一方で, はてなのReturn-Pathが超デフォルト値の「root@hatena.ne.jp」だったりしてほっこりしてしまいました.



Received-SPF: ....
Authentication-Results: ....
DKIM-Signature: .....


SPF (Sender Policy Framework), DKIM (Domainkeys Identified Mail) はメール認証技術でよく出てくるキーワードです. 詳しくは個別にググってもらえば良いかと思うのですが, 要するに「このメールの送信者は身元のしっかりした人ですよ」ということを証明する情報がヘッダーに含まれているのです.

メール認証が必要な背景として, スパムメールの蔓延があります.
メール転送システムはあまりにシンプルに設計されてしまったため, スパム業者の発信したゴミのようなメールがインターネット上を無限に飛び交っているのが現状です.
そのため, メールを受信したとしても, どこのどいつから送られたメールかわからなければ「スパム」と判定して迷惑メールフォルダにぶち込むという防御があらゆる場所で行われています. そんな世知辛い世の中に認証なしでメールを送るのは全裸で通勤ラッシュの山手線に乗り込むようなものです.



X-twfbl: 1307a328-ff32-484b-895f-f0f34efe1b2b


X-*からはじまる項目は送信者が独自に定義できる値で, 好きな様に使うことができます. 弊社が送るメールヘッダにX-JMTY: … という値を追加しても良いのです(たぶん). このX-twfblはなんかのGUIDっぽいのですが, 何なんでしょうね. Twitter社に聞いてみないとわかりません.



【DNSレコードを見てニヤニヤする】

さて上記の調査から, Twitterのメールサーバ(の少なくとも1台)は postmaster.twtter.com というFQDNを持っていることがわかりました. 次はこのサーバまわりのDNSレコードを洗い出してみましょう. nslookupでも良いのですがdigの方がなんとなく使いやすいのでdigをつかいます.

まず普通に正引きします(ANSWER SECTIONのみ表記, 以下同じ).

$ dig postmaster.twitter.com
postmaster.twitter.com. 272 IN A 199.59.148.144

次に, postmasterホストはメールサーバに使われているので, MXレコードを引きます.

$ dig postmaster.twitter.com mx
postmaster.twitter.com. 300 IN MX 10 mx1.twitter.com.
postmaster.twitter.com. 300 IN MX 10 mx2.twitter.com.

冗長化のためメールサーバが2台存在しているようです. IPアドレスを見ます.

$ dig mx1.twitter.com mx2.twitter.com
mx1.twitter.com. 2301 IN A 199.59.148.144
mx2.twitter.com. 2301 IN A 199.59.148.205

別のIPアドレスが割り当てられていることがわかります(冗長化ですしね).
逆引きしてみます. digで逆引きするには-xオプションを付けます.

$ dig -x 199.59.148.144
144.148.59.199.in-addr.arpa. 3569 IN PTR mx1.twitter.com.


mx1.twitter.com <-> 199.59.148.144 が
スパム判定の際にIPアドレスから逆に引き, ちゃんと元のドメインが帰ってくるかどうかをチェックしてスパム判定に使う方針もあるので, ここはちゃんと設定しておきましょう. EC2インスタンスとかでメールサーバを動かしてると逆引きしたときうっかりec2-…amazon.comみたいなドメインが帰ってきてしまい, 信頼性を落としかねないそうです.

上述のSPFレコードが登録されているかどうか確認するには, digでspfレコードをリクエストすれば良いです. mx1やmx2ではなく, 外から見える postmaster.twitter.com に対して引いてみます.

$ dig postmaster.twitter.com spf
postmaster.twitter.com. 600 IN SPF “v=spf1 ip4:199.59.148.224/27 ip4:199.16.156.131/27 mx ptr a:ham-cannon.twitter.com a:postmaster.twitter.com -all”

さすが, ちゃんと設定されています.


いじょ.


「ちゃんと設定している」Twitterを例にして盗み方を紹介して来ましたが, 身近なアイテー企業の設定を調査してみると「あらあらうふふ」みたいな状態が見受けられました. 完璧を期することは難しいですが, 知っておけば対策できる部分くらいはやっときたいところですね.

このへんの設定は実に面白いもんです. こんな記事を書いた以上, 弊社も他からm9(^Д^)プギャーされないように頑張ります.

投稿者: ジモティー | 2013年01月16日 | スタッフブログ - 最新の記事: 社内で出産ラッシュが続いています!... 記事一覧ページTopへ