SOHO環境でメールサーバをsendmail(Linux)で構築したのに、メールが送信できないという相談を受けました。
その Linux 上にはグループウェアが動いており、そのグループウェアからsendmailをキックしてメールを送りたかったようです。
あて先には Gmail を指定していたようなのですが受信できないとのこと。
ということで調べてみました。
どうやら Gmail は SPF という送信元ドメイン認証の仕組みを取り入れてるらしいです。
スパムメールのほとんどは送信元を偽装してるので、それを防ぐ仕組みですね。
具体的には送信元ドメイン(例:exsample.com)を管理してるDNSサーバのSPFレコード(もしくはTXTレコード)に、exsample.comのメールサーバのIPは aaa.aaa.aaa.aaa だよと定義しておきます。
メールを転送されてきた受け側のSMTPサーバは、エンベロープ送信元アドレス(メールサーバに渡される [MAIL From:user@domain] のアドレス)をチェックし、そのドメインのDNSサーバに、送られてきたメールの送信元IPが正当かどうかをチェックします。
エンベロープ送信元アドレスと送信元IPが異なる場合にスパムとみなすわけですね。
似たような仕組みに Sender ID と DomainKeys,DKIM というものがあります。
Sender ID は SPF とほぼ一緒ですが、違いは SPF が送信元ドメインの判定にエンベロープ送信元アドレスを使ってるのに対し、Sender ID はメールヘッダの情報から送信元ドメインを特定するということみたいです。(SPFの詳細と Sender ID との違いはSPF（Sender Policy Framework） : 迷惑メール対策委員会が分かりやすいです。)
DomainKeys と DKIM はメール送信時にメールサーバが電子署名を付与し、自身のドメインを管理してるDNSに署名に使う公開鍵を置きます。メールを受信したSMTPサーバはDNSサーバに公開鍵を取りに行き、それで照合がとれればOK,とれなければDNSのSSPレコード(ポリシー)を見てポリシーに従い結果を判断するという、ちょっとややこい仕組みのようです。
DKIM は DomainKeys の後継規格のようで、送信者アドレス単位での認証も可能になったり、SSP(Site Signing Policy)が厳密に定義されたりしてるようです。
(DomainKeys については@IT:電子署名を使うDomainKeysの設定方法、DKIMについては@IT:電子署名方式の最新技術「DKIM」とはが参考になります。)
SPF , Sender ID , DomainKeys , DKIM といった技術はメール転送時に送信元ドメインが正しいかどうかをチェックしてなり済ましを防ぐコンセプトに基づく技術ですね。
プロバイダが実施してる OB25P やメールサーバ上での SMTP 認証(またはPOP Before SMTP)はスパムの送信自体を元から断とうというコンセプトに基づく技術だと思います。
さて、本題に戻りますが、sendmail を構築してるSOHO環境は普通の家庭向けプロバイダサービスつまり動的IPでネット接続してます。
一応フリーのダイナミックDNSサービス(DynDNS)を使ってはいますが、Aレコードしか設定してません。
ただし、送信元アドレスはダイナミックDNSサービスで取得したホスト名を使ってます。
つまり、Gmailのサーバ側からするとSPFの認証が行えないわけですね。
ただSPFの認証ができない場合、Gmailは既定では迷惑メールに入れるようです。実際試したところ、迷惑メールに分類されてました。
またSPF認証できない場合は、メールヘッダの Received-SPF は下記のように neutral になるようです。
Received-SPF: neutral (google.com: xxx.xxx.xxx.xxx is neither permitted nor denied by best guess record for domain of hoge@exsample.com) client-ip=xxx.xxx.xxx.xxx;
この Received-SPF ですが、下記のような種類になるようですね。(参考:送信ドメイン認証（SPF）とsendmail - クネアシ)
pass: 送信元アドレスは正しく認証された
neutral: 送信元アドレスが詐称されているかどうか受信側で判断できない
softfail: 送信元アドレスは詐称されている可能性があるが、確定できない
fail: 送信元アドレスが詐称されている（認証失敗）
none: 送信元アドレスを認証するための情報が登録されていない
temperror:認証処理中に何らかの問題が発生し、認証できなかった
permerror:認証情報登録に誤りがある
Authentication-Results ヘッダにもドメイン認証の結果が入ってるようです。ここはSPF以外にも Sender ID や DKIM の結果も入るようですね。
詳しくは送信ドメイン認証『DKIM』のススメに各規格毎の認証結果がまとめられてます。
今回のようにダイナミックDNSの独自ドメインでメールサーバを立ててる場合にSPFに対応させるには、DNSのSPFもしくはTXTレコードに正当なSMTPサーバの情報を入れておけばいいようです。その方法は独自ドメインのメール送信を SPF に対応させる方法 - WebOS Goodiesで具体的にどういうレコード値を入れればいいのかが解説されてます。
ただ今回のようにフリーのダイナミックDNSサービス(DynDNS)ではDNSの細かいレコードは触れないので事実上無理ですね。
試しに、nslookup で gmail の SPF 設定見てみたところ下記のようになってました。
>nslookup -type=TXT gmail.com
Non-authoritative answer:
gmail.com text =
"v=spf1 redirect=_spf.google.com"
gmail.com nameserver = ns1.google.com
gmail.com nameserver = ns2.google.com
gmail.com nameserver = ns4.google.com
gmail.com nameserver = ns3.google.com
ns1.google.com internet address = 216.239.32.10
プロトコルがシンプルすぎるゆえに、メールサーバ立てて運用するのはWEBサーバほど簡単じゃないですね。
参考:
送信ドメイン認証『DKIM』のススメ SFP,Sender ID,Domainkeys,DKIMの違いが分かりやすいでです。
第16回 電子メールの送信ドメイン認証 送信ドメイン認証のかなり概略的説明です。
