CentOS8で構築する自宅サーバ:mailサーバの構築 その1 postfix設定方針

DNSサーバと同様に、メールサーバは他のメールサーバと連携するという点で、非常に重要なサーバです。

設定に誤りがあると、他のメールサーバに迷惑をかけることもあります。

ただ、最近のメールサーバの設定は、迷惑メール対策のおかげで非常に複雑になっています。

いきなり、今の設定を見ても、どうしてこの様になっっているのか、わからないかもしれません。

その1では、時代をさかのぼって、迷惑メール対策の変遷を書いてみたいと思います。

いにしえの迷惑メールがなかった時代

もともとの、メールの配送の流れについて図にしました。

略語について解説すると

  • MTA: Mail Transfer Agent。 いわゆるメールサーバです。sendmail,Postfix,qmailなどが配当します。
  • MUA: Mail User Agent。メールを読み書きするソフト。Outlook,Thanderbird,Becky!などです。
  • MAR: Mail Retrieval Agent。サーバに保存しているメールをMUAにわたすサーバです。qpopper,courier-imap,dovecotなどです。

かつてのメールサーバは、外部のMTAからのメールも、自組織内のMUAからのメールも、区別しないでsmtp(ポート 25番)で受けて、外部のMTAに転送したり、メールボックスに配送を行っていました。

オープンリレーの悪用

20世紀の終わり頃から、「外部のMTA→MTA→外部のMTA」とメールの転送(オープンリレー)が可能であることを、悪用して迷惑メールを出す人が出てきました。

リンクは、オープンリレーがなぜまずいのかと、その対策を解説した記事です。自分もInterlop98に見に行って聞いていました。

オープンリレーの対処として「外部のMTAからの①smtp送信」と「MUAからの②smtp送信」を区別する必要が出てきました。

基本的に「外部のMTAへの③smtp送信」は、以下の条件のIPアドレスからのものしか受け付けない、とするようになりました。

  • 自組織内のIPアドレスからsmtp送信されたもの
  • ⑥pop3受信時に認証が通ったIPアドレスからsmtp送信されたもの(POP before SMTP)

と、迷惑メールを出さないための対策を行いました。

また、迷惑メールを受信しないための対策として、オープンリレーになっているメールサーバのリストが有志により公開されていたので、それを利用し、「外部のMTAからの①smtp送信」時にIPアドレスをチェックし、リストに載っているものは拒否していました。

オープンリレーメールサーバのブラックリストは、
ORDB: Open Relay Database
MAPS: Mail Abuse Prevention System
のものをよく利用させていただきました。

また、オープンリレーのデータベースは、対策が進み役割を失ってなくなってしまいましたが、同時期に作成された、不正利用者のブラックリストは、今でも使っています。

Botnet来襲

オープンリレー対策が進んで、悪用されるメールサーバが少なくなると、今度は、ウィルスに感染したパソコンを利用して迷惑メールを出すことが流行りました。

ウィルスに感染したパソコンは遠隔操作によって、外部のMTAとして、迷惑メールを送りつけてきます。

1つのBotnetは数千から数万台になると考えられます。ブラックリストで対策したのでは、数が多すぎて対応できなくなりました。

対策として、一般のパソコンが「外部のMTA」の動作ができないように、各インターネットサービスプロバイダは、smtp送信を禁止するようになりました。(Outbound Port 25 Blocking,OP25B)

そのため、パソコンからメールを送信するときには、「MUAからの②submission送信」が必要になり、メールソフトも、それに対応するようになりました。

また、メールサーバ管理者として迷惑メールを受信しない方法として、

メールを送信しようとする外部MTAのIPアドレスを逆引きして、ホスト名が一般のパソコンに与えられるものに似ていたら、メール受信を拒否したり(S25R)

いきなり拒否は極端なので、S25Rと一旦拒否して再送を促すgraylistingの手法を組み合わせたりしていました。

今の迷惑メール対策は?

各ブロバイダのOP25B対応が功を奏して、Botnetによる「外部MTAとしての迷惑メール送信」は、2019年頃から、ほぼなくなりました。

現行のメールサーバでも、S25R+graylistingの仕組みは外して運用しています。

その代わりに目立つのがsubmissionの認証に対するログイン試行です。

安易なパスワードが付いているアカウントを狙って、submissionの認証を行い、認証が通ったら「MUAからの②submission送信」を使って大量の迷惑メールを送られます。

自分の自宅サーバも、この被害にあってしまい、該当アカウントはすぐに無効、メールサーバを停止して送信キューを削除、他にも安易なパスワードを使ったアカウントがないかチェックを行いなどで対応させられました。

他のメールサーバに迷惑をかけてしまったので、ブラックリストに載ってしまい、それを解除するにも苦労しました。特にgoogle様のgmail。

この対策として、submissionポート(587番)及びsubmissionと同じように使われるsmtpsポート(465番)については、特定のIPアドレス(例えば日本国内のもの)からしかアクセスできないようにするのが有効だと思います。

結局メールサーバの設定はどうしたら良いの?

メールサーバpostfixの設定として、各ポートごとにどのようにすればよいのかまとめます。

submissionポートとsmtpsポートのIPアドレスの制限は、Firewallで行う予定なので、postfixの設定の中に入れません。

smtp(25番)

基本、ローカルのメールアドレス宛のメールしか受け付けない。特定のIPアドレス(LAN内など)からのものだけ、メールの転送を行う。

ログイン試行を行わせないため、認証はしない。

相手の都合に合わせて、STARTTLSで暗号化を行う。

spamcopおよびspamhausのブラックリストに載っているサーバからのメールは受信しない。

submission(587番)

必ず認証は行う。

認証が通ったことを前提に、メールの転送を行う。

相手の都合に合わせて、STARTTLSで暗号化を行う。

smtps(465番)

認証は必ず行う。

認証が通ったことを前提に、メールの転送を行う。

暗号化は必ず行う。

なりすましメール対応

今まで、迷惑メールを受信しないことを中心に解説しましたが、もう一つなりすましメール問題もあります。

悪意ある人が、人のドメイン(例えばzeke.jp)を送信者のメールアドレスとして勝手に使って、迷惑メールを送信する。(外部のMTA1から①なりすましメール送信)

迷惑メールを受けたメールサーバは、宛先不明などのエラーメールを、送信者のメールアドレスであるzeke.jpのメールサーバに送信する。(外部のMTA2から②エラーメール送信)

zeke.jpのメールサーバは見に覚えのないエラーメールを大量に受信することになります。

エラーメールを送信するのは、善意の第三者なので、なかなか対策が取れなかったのですが、最近、送信ドメイン認証(SPF/DKIM/DMARC)で対応できるようになってきました。

送信した先でのメールの使われ方(転送など)をすべて把握していないと、送信ドメイン認証で正当なメールが拒否されてしまいます。

現状は、「自分のドメインで、なりすましメールが発生していないか?」のチェックぐらいにしか使えませんが、これもpostfixの設定に入れていきたいと思います。

最後に

迷惑メール対策は、時と共に変わります。

今の方法も、いつまでも続くのかわかりません。

とくに、他のメールサーバに迷惑をかけることもあるので、いつも見直しが必要になると考えています。

Kindle Unlimited入会で無料で読めます!

コメント