当社はIT技術のオンライン教育を得意としたセミナー専門会社です。 | 一戸英男

ITエンジニアの技術力UPをお約束します。

実験:OpenSMTPDでメールサーバ構築(CentOS7,Ubuntu Server(20.04.1 LTS)で最新設定仕様のファイルもあります。)

実験:OpenSMTPDでメールサーバ構築(CentOS7,Ubuntu Server(20.04.1 LTS)で最新設定仕様のファイルもあります。)


ちょっとメールサーバ(MTA)としては、レアなサーバを使って見ました。OpenSMTPDというBSD系UNIXでは知られているSMTPサーバらしい。ネットで調べてみると日本では情報が極めて少ないどんなもんかなーと思い構築してみました。メールは普段IMAPしか使いませんがちょっとレトロなPOPサーバでも入れて見ようかと懐かしいQpopperと組み合わせて見ようと思います。脆弱性とか色々あるけれどセキュリティツールでいくらでも抑え込めるので気にしない。 使ってみた感触は悪くないですね。設計の思想がまた他のMTAと全く異なるのでそこは面白い。postfixには無いこともできそうに思います。このMTAは受信ネットワークインターフェイス単位で制御を細かくできる点が素晴らしいです。本当はfilter文が使えるなら色々試せたのですが必要最低限セキュリティを担保して作ってみました。細かいヘッダやボディチェックはprocmailに任せ、DNSBLとベイジアンフィルターでスパム撃退を行っています。実際の25,587のフロントはfuというDNSBL smtpプロキシーで受信チェックしてそれから後ろにあるopensmtpdへ渡しています。

インストール

ソースでコンパイルしてもよかったが、依存ライブラリーを入れるのが面倒くさいのでパッケージインストールをすることに。epelがインストール済みなら問題無し。 後で調査してみたがopensmtpd-extras*はどうもopensmtpd起動時にロードできないようだ。バグかな。debianの過去issueで同じようなロードできないバグが見つかったので同類の問題か。。。 OpenSMTPDはOS環境によって出来具合いが違うという記述を見たので移植仕切ってなかった可能性はある。ソースでコンパイルするといけるかもしれ無いけども、まあしょうがない。

CentOS7の場合

Ubuntu Server

設定ファイルの作成

細かい解説は省く。インストールすると/etc/opensmtpディレクトリが生成されその配下にopensmtpd.confが出来ているのでそのファイルを編集します。受信箱に入る前にベイジアンフィルターbsfilterを使用しているため内部的にprocmailを使っています。その箇所は割愛します。opensmtpdは前述の通りDNSBLプロキシーから受け取った受信を後ろで待ち受けるためListenはローカルアドレスで受け取るようにしています。ubuntu serverでは、/etcの直下にsmtpd.confが生成されます。

上記の設定はCentOS7のバージョンなので現状は古い設定となっています。下記はUbuntu Serverの最新版 20.04.1 LTSで検証したものです。ディレクティブが所々微妙に違いがあります。DKIMとリレーのあたりの記述は結構苦戦しました。ほとんど資料がなくて当てずっぽうで書いてみた実験の末、ようやく動きました。約5時間程試行錯誤したかもしれません。Ubuntu Serverではデフォルトの設定パスが/etcの直下になります。設定ファイルは/etc/smtpd.conf

ユーザ登録関連ファイルの作成

サポートドメイン毎のユーザ登録

パスワードの作成と格納

メーラ側ではSMTP認証のタイプはプレーン認証(暗号化なし)を選ぶことになるが上記の通り内部では暗号化しているのでサーバに侵入されて盗まれたところで実害は無いと思います。接続タイプがSTARTTLS/SSLならまあ概ね安全じゃないでしょうか。

filter機能が使えないので、fuを経由してDNSBLをする。

extraパッケージが機能しないのでfilter文が無視される。しょうがないのでDNSBLをproxy仕様で対応することにした。尚、Ubuntu serverではfilter文が動作するか試しておりません。しかしfu自体はUbuntu Serverでも同様に利用できました。

DNSBL proxy fuの起動

Python2.7とするかpythonとするかはセッティング次第なので環境に合わせてください。

DKIM Proxyの設定

postfixでおなじみのOpenDKIMは使えないという噂なので、 DKIM Proxyを使用します。dkimproxy用のユーザ作成は必要です。dkimユーザを予め作っておいてください。

DKIM Proxyのサービス登録

DKIM用のDNSレコード設定は他のSMTPサーバと同様なので割愛します。

DKIM proxy起動

qpopperのインストール

Qpopper設定ファイル

/etc/qpopper995.cfgファイルの編集

xinetdのインストール

ログローテーションの設定

APOPのユーザ登録

APOP仕様にするとメールソフトの設定でパスワードの暗号化(CRAM-MD5)が選択できます。

Firewalldで必要なポートをオープンします。

ポート番号、25,587,995をオープンします。

Ubuntu serverの場合ufwでFirewallオープンします。

Ubuntu serverではpopsにdovecotを使う

qpopperのコンパイルがgccのバージョン関連の仕様相違があり、コンパイルできませんでした。ソースコードを改変するのもかったるいのでdovecotでいきました。

pop認証の編集

メールボックスの形式設定

SSLの設定

ユーザ認証の認証タイプを設定

ユーザ認証形式とDBの所在を設定

ユーザパスワードの書式設定

ユーザのパスワードファイル設定

「doveadm pw」で実行した内容と/etc/passwdを合成して/etc/dovecot/passwdを生成してください。以下のような形式です。

dovecotの起動

タグ: , , , , , ,

ブラックリストへの考察 メールのSPAMチェック DMARC、DNSBLについて


昔よりも更に複雑になったと思うサーバの種類にメールシステム(smtpサーバ:MTA)がある。振り返ってみると20年くらい前はデフォルトで作ったメールサーバでもすぐにインターネット上で使えましたが、今は兎に角セキュリティが厳しいので単純な設定ではまともに動かない。ガチガチだなーと感じる。時折サーバ講義の仕事をすると一番厄介なのがメールサーバの解説。正直言って1週間勉強した程度で理解できるのは初心者程度の知識だと思う。アンチSPAMの仕組みについては年々高度になっている。油断しているとおいて行かれるので定期的に情報に目を通さなければならないが、最近の技術の中ではDMARCはさすが効果あるね!と実感できる仕組み。この機能はSMTP通信におけるなりすましを確実にブロックしてくれる。単純ななりすましなら100%ブロックできるだろう。送信サーバがスパイウェアに感染していたら駄目だと思うが、そうなっていない限り大変安全な仕組みと思う。

DMARCを使用してよかった事

以前は、時折自分のメールアドレスFromで数は多くはなかったが1年に2,3回程度送信されてくることがあったがDMARCを導入してからはピタリと止まった。更に嬉しいことに偽メールを送られた受信メールサーバからレポートがxmlで送られてくるので実態が掴める。殆どがgmailとyahooメールからのものだが、これだけ人の名前とメールアドレスを騙って送る輩がいたのだと気付かされる。つまり実際にはもっと沢山偽メールが横行していたと考えられる。もちろんDMARCを実装しているメールサーバでなければこのようなやり取りはできないが、今後必須のシステムになってきそうだと思います。特にビジネスで利用されている企業は共有ホスティングのおまけでついてくるメールは使ってはいけないと私は思います。

DMARCの導入は難しい?

メールサーバの導入になれている人なら1,2時間の学習でDMARCは導入できると思います。DKIM,SPFを入れた経験があるならすぐに理解できると思います。少しDKIM,SPFでやったような作業がつきまといますが非常に難易度の高いものではありません。作業の中にDNSのレコードを操作する箇所があるのでDNSを知らない人は大変かもしれませんがぜひチャレンジしてみてください。CentOSでやるよりもUbuntuのほうがハードルが低そうです。

DNSBLの信頼性

DNSBLシステムは世界に点在しブラックリスト情報を収集して無料で使えるメールSPAM対策サービスが幾つかある。このサービスはDNSの仕組みを利用したレピュテーションサービス(ブラックリストの判定を返す)だが運営組織が何しろ非営利な組織だから出来ては消えての繰り返し。日本ではRBL.JPという日本のスパムデータ・ベースもあったが廃止されており、現在はほとんど海外のサービスを利用するのが多くなった。厄介なのは昨今のIPアドレス汚染だ。プロバイダーの持っているIPアドレスはリサイクルされるため、過去にブラックだったIPだとかなり厄介になることがあります。というのはDNSBLやWEBのブラックQUERYサービスの中にはネットワークブロックで設定しているケースが少なからずあるからだ。そうするとホワイトなIPアドレスでもブラック扱いにされてしまう可能性が十分にありえます。誤判定の多くは過去のIP悪さが起因するのもあるけれど、このようにネットワークマスクの縛りが原因でなってしまう場合もあります。IPアドレスのご判定は殆どが申請で取り消せるようになっていますがネットワークブロックで管理している場合は無理な時もあります。その意味でサーバを借りるときは必ずIPアドレスのチェックを行うことと、IPアドレスの再割り当てができるホスティングがベストです。

SPAM対策用のmain.cfの一部抜粋

reject_rbl_client が記述されているあたりがDNSBLのサーバエントリー。お付き合いしている会社により効きすぎたり、効かなすぎたりあるため使いながら外したりして調整を行う。

共有サーバは勘違い判定の巣窟になる。

共有サーバは1台のサーバに多数のサイトが運営されるサーバですが、このサイトの中に詐欺サイトやマルウェア感染原因のサイトがあるとどうなるかご存知でしょうか?プロバイダーが認識した場合はプロバイダーから改善通知や停止を言われますが、実際のところ運営者も気づいていないものもかなりあると思います。私も自分のお客様で幾つかこの様な例を経験しましたが、結論はGoogleやYahooの検索結果に出てこなくなりました。イメージ的にはGoogleのインデックスには残っているのでしょうが、一時的にマスクされているように思えます。ブラック発見は無料のbaraccudacntral.orgのサービスでチェックし、その後別のプライベートホスティングに移設しDNSを切り替えたところ5分で検索結果にTOP5で表示されるようになりました。この経験でGoogleが如何に様々な詐欺行為のサイトを抑え込むチェックを行ってるかがわかりました。ビジネスで本気勝負をかけて集客、販売する会社は共有サーバ使ってはいけませんね。

タグ: , , ,