前回までに家庭内メールを dhcp さんに集約して、ナンチャッテ証明書でサーバの認証とデータの暗号化ができるようにしてきました。今回は DKIM によるメールの内容に対しての署名を行って、gmail.com に作ったお試しアカウントでメールの正当性を確認しようと思ったのですが、問題が起こりました。OP25B 問題です。
OP25B
現在のように SNS 全盛ではなく、まだメールが全盛のころ、何でもかんでもメールで配信しており、正規、不正にかかわらず得たメールアドレスのリストさえあれば家庭のネットワークなどに SMTP サーバを立てて、そのメールアドレス宛に送り付ければ、DNS が配送先を教えてくれるので、ほぼ確実に届くことから当時はこの手の SPAM が横行するようになりました。そこで、ISP としての対策として、各 AS 境界で SMTP で使用される tcp port 25 をブロックすることを行いました。これで ISP A の正規のメールサーバ以外から ISP B のメールサーバにメールを送ることはできなくなるのですが、プロバイダを跨いだ正規のメールユーザもメールを送信することができなくなります。そこで、SMTP で使用される tcp port 25 に加えて、tcp port 587 ( submission ポート ) を使用して認証をパスすることで、port 25 と同様にメールサーバを利用できるようにしました。ですので、これから作ろうとしているメールサーバから送出されるメールは ISP が異なるので SMTP セッションが確立せず、メールを送ることができません。これが OP25B ( Outbound Port 25 Blocking ) です。現在でも SPAM メールの流通量は相当あるのですが、当時は ISP 料金が現在に比べて高価であったことからこのような方法をとっていたと思われるのですが、現在では非常に安価にビジネスユースのネットワークを購入できるので、OP25B 問題のないビジネスユースネットワークに正規のメールサーバを立てて、そこから SPAM を送っている輩が多いと聞いています。私が使用している ISP は家庭用のごく普通の ISP ですので、まさに作ろうとしているメールサーバーはスパムサーバの扱いになります 🙂 こんな感じでブロックされます。yahoo.co.jp さんの場合です。
当然 gmail.com さんの場合も smtp ポートはブロックされています。これらは受信専用のメールサーバのようで、submission ポートは開いていないようです。内部事情を知らないと私設 SMTP サーバからおいそれとメールを送ることができません。
では、内情を知っている SMTP サーバではどうでしょう？私が使用している ISP とレンタルサーバの ISP は異なります。前回までに内部の DNS と外部の DNS で異なるレスポンスを返すようにしました。
内部事情のスクリーンショットはモザイクだらけになります 🙂 知られて困ることはないのですが、オープンにする必要もありませんので、私設メールサーバが完成するまで変えずに置きたいと思います。ただ、モザイクの部分は他の部分から得られるので大きな意味はないのですが…とりあえず…
ご覧のように smtp ポートはブロックされていますが、submission ポートはアクセスできます。ですので、この submission ポート経由で smtp 認証をパスさせて、このサーバにリレーさせるようにします。今回書こうと思っていた DKIM 署名がリレーサーバ経由でも有効かどうかは調べていませんが、とりあえず今回は submission ポート経由の SMTP AUTH をパスできるようにして、DKIM 関連は次回以降に先送りとします。前回までに dhcp さんの /etc/mail ディレクトリはこのようになりました。特に大きな変更はなく、local-host-names ファイルが増えただけです。
masquerade_entire_domain
今回は DKIM の前準備としてメールヘッダの整理を行い、SMTP AUTH をパスさせてどこへでもメールを送れるようにします。まず、メールヘッダの整理を行います。現在使用している sendmail.cf はオリジナルの freebsd.mc ファイルをベースにして作られたファイルです。ですので、このファイルをコピーして変更を加え、そのファイルから sendmail.cf ファイルを作りたいと思います。
sendmail 関係のドキュメントは /usr/share/sendmail/cf ディレクトリにあります。中でも README ファイルは最初に読むべきファイルで、各種パラメータ、変数のデフォルト値や、sendmail で提供されている各種マクロや、何をするにはどうすればよいかなどの HOWTO などが書かれています。ほぼこのファイルを読むことで何でもできるはずです。まず行いたいことは家庭内で user@hostname となっているメールアドレスを user@jf3vqb.net に書き換えるルールセットが必要になります。それを探してみると、masquerade_entire_domain 部分に書かれています。このルールセットを追加して sendmail.cf を作ってテストしてみます。
メール From は期待通りに書き換わりましたが、それ以外はホスト名が使われています。外部のホストに直接 pokemon さんあてに送ってもらう事は期待しませんので、この辺りも jf3vqb.net に書き換えます。
お試しメールを送ってヘッダを見てみます。ずっとましになりました。
authinfo
次は、外部のメールサーバにメールを送ってみてヘッダがどう書き換えられたかをテストしてみるのですが、それには SMTP AUTH 経由でメールを送れるようにしなければなりません。その変更を行います。同じように README を読んでゆくと、authinfo のところに書かれています。jf3vqb.mc を変更して sendmail.cf を作成します。
そして、README にあるとおりに /etc/mail/authinfo ファイルを作成して、これを基にハッシュファイルを作成します。README ファイルの 70% あたりにサンプルが書かれていますので、自分の認証情報で置き換えます。モザイクだらけで何が何だかわからん状態です 🙂 README からの抜粋です。
- AuthInfo: remote hostname
- U: user (authorization) id
- I: authentication id
- P: password
- R: realm
- M: list of mechanisms delimited by spaces
接続先の OS により各種の認証方法があります。使用する認証方法に必要なパラメタのみを記述します。ここで使用している M:LOGIN では base64 でエンコードされたユーザ名とパスワードが使用され、それらの文字列はユーザ名やパスワードを変更しない限り毎回同じ値です。リプレイ攻撃を食らったらひとたまりもありません。ですので、ネットワークセッション自身が暗号化されていることが最低限必要です。これ以外にも、ユーザ名とパスワードからハッシュ値を作って送るなどもできます。今回は必ず暗号化を行ってから認証を通すので、これで良しとします。勿論利用可能な方法をスペースで区切って書くこともできます。
何が利用できるかは telnet などで submission ポートに接続することで確かめることができます。authinfo ファイルを作る前に確かめときます。こんな感じです。
SMART_HOST
期待する動作として、例えば pokemon さんから test@gmail.com 宛にメールを送ると、dhcp さんでリレーされて、さらに ISP の正規のメールサーバでリレーされて gmail.com の MX ホストへとメールがリレーされてほしいわけです。試しに送ってみます。
あちゃー、直接送ってしまったようです。そこで、スマートホストをセットします。例の README を読むと 42% のあたりに記述があります。pokemon さんの freebsd.mc ファイルを編集してスマートホストを dhcp さんであると記述して sendmail.cf を作り直します。実は見比べてもらうとわかるのですが、１行異なるだけです。ですから mc ファイルから作り直さなくとも cf ファイルを直接編集してリレーサーバ名を追加することでも OK です。sendmail の再起動を忘れないでください。
気を取り直して送り直しです。
ん？送り返された感じ？dhcp さんのログを見てみます。
/etc/mail/access
リレーを許していなかったようです 🙁 家庭内のサーバにリレーを許しましょう。/etc/mail/access ファイルで制御できるはずです。
サンプルをコピーしてリレー OK としてハッシュファイルを作ります。
home.jf3vqb.net ドメインのホストに許可したつもりになっていますが、これで大丈夫でしょうか？DNS には順引き検索と逆引き検索があります。*.home.jf3vqb.net -> IP アドレスの登録は私しかできません。でも逆を考えてください。逆引きはソースアドレスを持つ別のプロバイダの DNS で登録することができます。ですので、8.8.8.8 が ggl.home.jf3vqb.net であると DNS ポインターレコードを作ると、dhcp さんの sendmail は 8.8.8.8 からリレー要求があるとリレーを許してしまいそうです。が、実はもう少し複雑なチェックをしています。悪意のある 8.8.8.8 から接続があると、dhcp さんは逆引きを行い、接続が ggl.home.jf3vqb.net からであると知ります。すぐにリレーを許すのではなく、dhcp さんは ggl.home.jf3vqb.net から IP アドレスを得ます。これで得られた IP アドレスが元の 8.8.8.8 にマッチすると home.jf3vqb.net ドメインからのアクセスであると認定します。今回の場合、手元の DNS に ggl.home.jf3vqb.net は作っていません。ですので、8.8.8.8 からのアクセスは home.jf3vqb.net ドメインからのアクセスとは認定しません。つまり、リレーは許可されません。では、再度実験を行ってみます。
今回は正常にリレーされたようです。dhcp さんでもログを見てみます。
dhcp さんもリレーの設定を忘れていました 🙁 pokemon さんと異なるのは submission ポートを使用して SMTP AUTH をパスさせることです。SMTP AUTH の設定は追加済みなので、スマートホストを追加します。
さて、先ほどと同様にテストメールを送って dhcp さんのログを見てみます。
SASL
ログから ISP のリレーサーバへは送り付けるようになりましたが、認証を通過していない、あるいは submission ポートを使用していないと思われます。tcpdump などで確認してみてもよいかと思います。そこでまた README の出番です。読み進めると、SASL オプションを ON にしてコンパイルされた sendmail かどうかを調べる必要があるようです。このオプションは SMTP AUTH の使用と、少々高級な認証方法を M:LOGIN などの代わりに使用したいとなると必要になると書かれています。ですのでコンパイル時のオプションを確認してみます。
dhcp さんで使用している sendmail は OS 付属の sendmail で、見る限り SASL オプションは見て取れません。では、SASL オプションを ON にして作り直しましょう。さて、ここで考えます。OS 付属の sendmail を作り直すか？ /usr/ports/mail/sendmail のポーツを使用するか？ ポーツ版を見てみると、バージョンが 8.17.x と書かれています。一方、OS 付属版は 8.16.x です。どうせ作り直すのであれば、新しいほうにしましょう。それに OS 付属版は OS のアップデートがあると、SASL なし版に書き換えられることがあります。そうすると、なぜ SMTP AUTH が動かなくなったのかわからなくなり、悩むことになります。ですので、ポーツ版に SASL オプションを加えてコンパイルして使用します。
うまくいったようです。メッセージに従って使えるようにします。
このメッセージには /usr/local/etc/mail の mailer.conf を云々と書かれていますが、元々ある /etc/mail ディレクトリをそのまま使用したいので、/etc/mail/mailer.conf に細工をします。
これで sendmail を動かしなおすと、今作った新しい sendmail が使用されます。
バージョンが異なるのですぐにわかります。SASL オプションも確かめておきます。
OK 牧場のようです。では気を取り直してテストメールを送ってみます。
submission connection
見た目の症状は同じなのですが、SMTP AUTH を試す前に、セッション自身が確立していないように見えます。またまた README の出番です。README の 9% あたりに、RELAY_MAILER_ARGS のデフォルトは [TCP $h] であると書かれています。つまり tcp port 25 での接続を行っているようです。ポート番号を指定します。
ん？ /usr/local/sbin/sendmail にポーツでインストールしました。/usr/share/sendmail/cf のファイルを使って OK ? たぶん OK なのでしょうが、念のためにポーツ付属のファイルで作れるように Makefile を修正します。
OS 付属の cf ファイルで作った sendmail.cf と比較してみます。
こんなに違いがあるのであれば、新しい cf ファイルを使わない理由はありません。ですので、置き換えてテストします。
ほぼよさげです。mailer=relay でステータスは sent です。ただ、verify は FAIL なので、ナンチャッテ証明書に細工を行います。正規の root 証明書を追加して sendmail を再起動します。
これで最終テストを行ってみます。
私の管理下にある部分は全て OK のようです。gmail.com で受け取ったメールのヘッダを見てみます。と、思ったのですが、モザイクをかけると何が何だかさっぱりわからなくなりますので、結論だけを書きます。ソース側のメールアドレスは envelope from も含めて全て pokemon@jf3vqb.net に書き換わって届いていました。ただ一点、ISP のメールサーバでの STARTTLS の verify は FAIL になっています。ナンチャッテ証明書は対外的には効力を持ちません。期待通り暗号化されているので問題は無いと思いますが、ここまで気にするのであれば正規の証明書を買いましょう 🙂 因みに、SMTP プロトコルの標準に暗号化はありません。サーバーは暗号化のオプションがあることを示すだけで、強要はできません。あくまで暗号化を行うかどうかはクライアント側のオプションです。次回は DKIM の署名を付けてみましょう。因みにここまでのメールフロー図はこんな感じです。
以下広告
コメント