前回は、メールバーチャルホストと管理用のPostfixAdminのセットアップを進めました
今回は、SPF/DKIM/Dmarcを使った送信メールの信頼度向上と、受信メールのフィルター実装を進めます
今回のコンポーネント
今回はコンポーネントが山盛りですね。
| コンポーネント | 利用しているもの |
|---|---|
| MTA | Postfix 3.4.13 |
| POP/IMAPサーバ | Dovecot 2.3.7 |
| メールボックス管理 | PostfixAdmin 3.2.1 |
| SSL証明書 | Let's Encrypt |
| DNS | Bind 9.16.1 |
| データベース | MariaDB 10.3.25 |
| DKIM | OpenDKIM 2.11.0 |
| DMARC | OpenDMARC 1.3.2 |
| グレーリスト管理 | postgrey 1.36 |
| Log Report | Pflogsumm 1.1.5 |
| SPAM管理 |
SpamAssassin 3.4.4 |
| ウィルススキャン （当初導入するも、メモリ不足で無効化） |
Amavis 2.11.0 ClamAV 0.103.2 |
当初、ウィルススキャンとしてAmavis/ClamAVを導入しました。
メモリが2GBでは足りなかったため最終的には無効化していますが、導入手順はメモとして記載しています。
今回は、メールサーバ構築に関して理解しながら進めるために、段階的にステップを踏みながら構築を進めていきます。
- Postfixサーバの基本セットアップ
- TLS暗号化とDovecot IMAP/POP3サーバセットアップ
- PostfixAdminを使ってバーチャルメールボックス作成
- 信頼度向上のためのSPF/DKIMレコード作成
- ドメイン信頼性向上のためのDMARCセットアップ
- Postfixでのスパム受信ブロック
1ページでの記載には大きすぎたので記事を分割します
今回の記事では、信頼度向上に向けてSPF/DKIMレコードの作成、DMARCセットアップとSTEP4とSTEP5を記載します。
STEP4.信頼度向上のためのSPF/DKIMレコード作成
SPF (Sender Policy Framework)とは
SPF (Sender Policy Framework)とは、 電子メールの送信元ドメインが詐称されていないかを検査するための仕組みです。 SPFの仕様は、 RFC4408(*1)で定められています。
インターネットでメール送信に使用されるプロトコルであるSMTP (Simple Mail Transfer Protocol)は、 差出人のメールアドレス(Fromアドレス)を自由に設定することが可能です。 このため、 送信元を偽った「なりすましメール」を簡単に送ることができてしまい、 これが迷惑メールに利用されてきました。
SPFは、こうしたメールアドレスにおけるなりすましを防ぐための技術の一つで、 DNSを利用するのが特徴です。 ドメインをSPFに対応させるには、 そのドメインのゾーンデータにSPFレコード(*2)という情報を追加します。 SPFレコードには、 そのドメイン名を送信元としてメールを送ってもよいサーバのIPアドレス等を記述します。
一方、SPFに対応したメール受信サーバは、 メールの受信時にそのメールの送信元となっているドメイン(*3)のSPFレコードを、 DNSで問い合わせます。 送信元のサーバがSPFレコード中で許可されていない場合は、 送信ドメインの詐称が行われたと判断して、 受信を拒否するなどの処理を行います。
つまりSPFは、送信元サーバのIPアドレスとDNSを利用して、 あらかじめ想定された送信元以外からのなりすましメールを検出できるようにする機構で、 より多くのドメインがこの仕組みに対応することで、 その効果が高くなります。
*1 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
http://www.ietf.org/rfc/rfc4408.txt
*2 SPFレコードのためのRR(リソースレコード)として"SPF"がRFC4408で定義されていますが、 これを扱えないプログラムのために、 同RFCでは併せてTXTレコードでも同一の内容を記述するべきとされています。
*3 RFC4408では、 envelope from (SMTPのMAILコマンドで使用されたメールアドレス)のチェックは必須で、 HELOドメイン(SMTPのHELOコマンドで使用されたドメイン名)のチェックも推奨されていますが、 どのドメイン名を使うかは実装により異なります。
SPFレコードの設定
SPFレコードと言いますが、DNSにSPFという名前のレコードはありません。TXTレコードにSPFに関する記述を行います。
メール送信に利用するサーバアドレスを11.22.33.44とした場合、該当ドメインのTXTレコードに"v=spf1 ip4:11.22.33.44 ~all"のように記述します。
例としてBINDのzoneファイルに以下のような項目を追加します
| @ 300 IN TXT "v=spf1 ip4:11.22.33.44 -all" |
「ip4」はIPv4アドレスの指定であること
「11.22.33.44」は正当なメールサーバのIPアドレス
「-all」はそれ以外は送信元メールアドレスが詐称されていること（断定）を示します。
| @ 300 IN TXT "v=spf1 ip4:11.22.33.0/24 ~all" |
上記例のように、送信元をネットワークアドレスレンジで指定することも可能です
「~all」はそれ以外の送信元メールアドレスは詐称されている可能性があることを示します。
「-all」が良いと感じる方も多いと思いますが、下記のような際にSPFチェックではじかれる可能性を考慮すると「~all」をお勧めします。
メール受信者側のMXサーバが冗長されていた際に、受信者側のプライマリMXサーバがダウンした際は、セカンダリMXサーバにメッセージを送信され一時的に保留されることがあります。
その後、プライマリMXサーバが復活した際は、セカンダリMXサーバはプライマリMXサーバにメッセージを転送した際に、リレー元サーバがSPFで指定されていないためSPFチェックではじかれる可能性があります。
| @ 300 IN TXT "v=spf1 a:mail.your-domain.com ~all" |
送信元の指定をAレコードで指定することも可能です
| @ 300 IN TXT "v=spf1 mx ~all" |
こちらは、MXレコードで指定されたメールサーバが正当という意味になります。
| @ 300 IN TXT "v=spf1 ip4:11.22.33.0/24 include:spf.securemx.jp include:_spf.atlassian.net -all" |
メールサービスを利用していたり、クラウドツールなどからメール送信をする場合は、プロバイダが用意するSPFレコードに記載された内容を取り込むことも可能です
SPFレコードは複数の記述を並べることも可能です
| @ 300 IN TXT "v=spf1 ip4:11.22.33.0/24 -all" @ 300 IN TXT "v=spf1 include:_spf.atlassian.net -all" |
複数のTXTレコードを記載することはできません。正しく判断されなくなります。
SPFレコードが正しく記述されているか確認する方法
インターネット上で無料公開されている、SPFレコードチェックツールなどを利用することが可能です。
SPF Record Testing Tools
https://www.kitterman.com/spf/validate.html
受信メールのSPFチェック
続いて、自分が受信するメールのSPFチェックを行うツールをインストールします
SPF Policy Agentのインストール
パッケージ（apt）で用意されているSPF Policy Agentを導入します
# apt install postfix-policyd-spf-python
Postfix設定変更
/etc/postfix/master.cfを編集します
末尾に下記項目を追加します
| policyd-spf unix - n n - 0 spawn user=policyd-spf argv=/usr/bin/policyd-spf |
/etc/postfix/main.cfを編集します
末尾に下記項目を追加します
policyd-spf_time_limit = 3600 smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service unix:private/policyd-spf |
各項目の詳細は次回説明しますが、メールを受信する際のSMTP手順において、RCPT TOコマンド受信時にSPFのチェックを行います。
Postfix再起動
設定を反映するため、Postfixを再起動します
# systemctl restart postfix
テストメール受信
SPFレコードが適切に設定されたドメインからのメールを受信すると、メールヘッダに以下が追加されます
| Received-SPF: Pass |
続いてDKIMの設定を進めます
DKIMとは
DKIM (DomainKeys Identified Mail)は、 電子メールにおける送信ドメイン認証技術の一つであり、 メールを送信する際に送信元が電子署名を行い、 受信者がそれを検証することで、 送信者のなりすましやメールの改ざんを検知できるようにするものです。
送信ドメイン認証技術は、送信元のIPアドレスを利用するものと、 電子署名を利用するものとに大きくわかれますが、DKIMは電子署名を利用し、 その電子署名の検証に必要となる公開鍵は送信元ドメインのDNSサーバで公開されます。 受信者は受け取ったメール中の署名者に関する情報からドメインを特定し、 そのDNSサーバへ問い合わせることで公開鍵を取得します。
電子署名の作成は、送信者自身が必ずしも行う必要は無く、 他にメール送信者の利用するメール中継サーバ(MTA)、送信メールサーバ(MSA)、 あるいは信頼した第三者が行うことが可能です。 このような特徴を利用して、 例えば電子署名の作成をメールサーバで行うように設定を行い、 エンドユーザーのメールに対して透過的にDKIMを用いた署名を付加することなどができます。
最近では、同じ送信ドメイン認証技術でも送信元のIPアドレスを利用するSPF (Sender Policy Framework)と、 DKIMとを組み合わせたDMARC (Domain-based Message Authentication, Reporting and Conformance)と呼ばれるメール認証技術の導入に伴い、 DKIMの普及が進んでいます。
■参考
RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
https://tools.ietf.org/html/rfc6376
RFC 6377 - DKIM And Mailing Lists
https://tools.ietf.org/html/rfc6377#ref-DKIM
DomainKeys Identified Mail (DKIM)
http://www.dkim.org/
インターネット用語1分解説～SPFとは～
https://www.nic.ad.jp/ja/basics/terms/spf.html
dmarc.org - Domain Message Authentication Reporting & Conformance
https://dmarc.org/
M3AAWG Sender Best Common Practices
https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf
DKIMの導入
OpenDKIMインストール
パッケージ（apt）を利用してOpenDKIMをインストールします
# apt install opendkim opendkim-tools
ユーザpostfixをグループopendkimに追加
OpenDKIMの各種ファイル類にアクセスを可能とするために、Postfixのプロセス実行ユーザであるユーザpostfixをグループopendkimに追加
# gpasswd -a postfix opendkim
OpenDKIM設定ファイル編集
# vim /etc/opendkim.conf
下記3行をコメントを外し、Canonicalizationのパラメータをsimpleからrelaxe/simpleに変更します
| # Commonly-used options; the commented-out versions show the defaults. #Canonicalization simple #Mode sv #SubDomains no Canonicalization relaxed/simple Mode sv SubDomains no |
下記を末尾に追加します
|
# Map domains in From addresses to keys used to sign messages # Hosts to ignore when verifying signatures # A set of internal hosts whose mail should be signed |
簡単にパラメータの解説をします
Canonicalization (string型)
Canonicalizationディレクティブはメールヘッダ/ボディのフォーマットをどれくらい厳格にするかを指定するポリシーです。
メールは送信経路上で予期せず（勝手に）改変されることがあります。（例：タブを空白に変換）
全く改変を許容しないsimpleと多少の変更は許容するrelaxedがあり、今回はヘッダはrelaxed、ボディはsimpleに指定しています。
Mode (string型)
Modeディレクティブにはs(sign, 署名)とv(verify, 検証）があります。
今回は両方を対応するためsvとしています。
SubDomains (boolean型)
SubDomainsディレクティブはサブドメインの利用有無を指定します。
尚、OpenDKIMではBoolean型は1文字目のみで判定を行います。肯定の場合は”T",”ｔ”、”Y”、”ｙ”、”１”、否定の場合は"F"、"f"、"N"、"n"、"0"となります。
今回は視認性を考慮して"no"と記載しています。
KeyTable (dataset型)
KeyTableディレクティブはキー名を署名鍵にマッピングするファイルの場所を指定します。
refileは正規表現を使用する場合のファイル指定方法です
SigningTable (dataset型)
SigningTableディレクティブは、From： ヘッダーフィールドにあるアドレスに基づいて、メッセージに適用する1つまたは複数の署名を選択するために使用されるテーブルを定義します。
refileは正規表現を使用する場合のファイル指定方法です
ExternalIgnoreList (dataset型)
ExternalIgnoreListディレクティブは、検証対象外とする外部ホストを定義します
InternalHosts (dataset型)
InternalHostsディレクティブは、署名対象とする内部ホストを定義します。
Signing Table、Key Table、Trusted Hosts File作成
設定ファイル用ディレクトリ作成
/etc/opendkimをopendkimの設定ファイル用ディレクトリ、/etc/opendkim/keysをキーファイル保管用ディレクトリとします
利用ドメイン用のキーファイル用に/etc/opendkim/keys/your-domain.comを作成します（ドメイン名は適宜修正）
各ファイル・ディレクトリの所有者をopendkim:opendimとし、キー保管用ディレクトリは秘密鍵が保管されるため所有者以外のアクセス権を外します
# mkdir /etc/opendkim
# mkdir /etc/opendkim/keys
# mkdir /etc/opendkim/keys/your-domain.com
# chown -R opendkim:opendkim /etc/opendkim
# chmod 700 /etc/opendkim/keys
Signing Table作成
opendkim.comfのSighningTableディレクティブで指定したファイル/etc/opendkim/signing.tableを作成
# vim /etc/opendkim/signing.table
内容は以下となりますが、ドメイン名は適宜修正ください
| *@your-domain.com default._domainkey.your-domain.com |
Key Table作成
opendkim.comfのKeyTableディレクティブで指定したファイル/etc/opendkim/key.tableを作成
# vim /etc/opendkim/key.table
内容は以下となりますが、ドメイン名は適宜修正ください
| default._domainkey.your-domain.com your-domain.com:default:/etc/opendkim/keys/your-domain.com/default.private |
Trusted Hosts作成
opendkim.comfのExternalIgnoreListディレクティブとInternalHostsディレクティブで指定したファイル/etc/opendkim/trusted.tableを作成
# vim /etc/opendkim/trusted.hosts
構成によりますが、今回はメール送受信を行う内部サーバを対象として同一ファイルをExternalIgnoreListとInternalHostsで利用しています
|
127.0.0.1 |
秘密鍵/公開鍵のキーペア作成
DKIMでは送信メッセージへの署名とメッセージの受信検証のために、署名のためのプライベートキーとリモートの確認者のためにパブリックキーを作成します。
パブリックキーはDNSを使って広報します。
opendkim-genkeyツールを利用して鍵作成
# opendkim-genkey -b 2048 -d your-domain.com -D /etc/opendkim/keys/your-domain.com -s default -v
鍵長（-b）を2048bit、対象ドメイン（-d）をyour-domain.com、対象ディレクトリ（-D）を/etc/opendkim/keys/your-domain.com、セレクター（-s）をdefaultとしています。
セレクターを日付としている紹介記事もありますが、一つのドメインで複数の鍵をするなど特殊な用途以外では不要なので今回はdefaultとしています。
コマンドを実行すると指定ディレクトリに、秘密鍵default.privateと公開鍵default.txtが作成されます
鍵の所有者変更
# chown opendkim:opendkim /etc/opendkim/keys/your-domain.com/default.*
公開鍵をDNSレコードに追加
# cat /etc/opendkim/keys/your-domain.com/default.txt
BINDを利用している際はdefault.txtの内容を鍵の分割記載や改行を含めてそのまま該当ドメインのzoneファイルに記載します。
BINDでは一つの文字列は最長255文字という制限があります。RFC4408の定義により255文字以上を連結する際は連結部分に空白を入れることにより確認側が同一レコードと判断します。
無理に公開鍵を一行にまとめようとすると正しくゾーンファイルを読み込んでくれないため注意が必要です。
確認
opendkim-testkeyコマンドを利用いて確認を実施します
# opendkim-testkey -d your-domain.com -d your-domain.com -s default -vvv
key OKと結果が表示されればOKです。
| opendkim-testkey: using default configfile /etc/opendkim.conf opendkim-testkey: checking key 'default._domainkey.your-domain.com' opendkim-testkey: key not secure opendkim-testkey: key OK |
DNSSECを利用していない場合、「opendkim-testkey: key not secure」と表示されます
私が利用しているレジストラ（お名前.com）ではDNSSECの利用はレジストラ提供のレンタルDNSサーバの利用が必須となっており、Let's Encryptのワイルドカード証明書の自動更新のためプライマリネームサーバを自家用サーバを利用しているためDNSSEC対応ができないため現時点では許容している
PostfixとOpenDKIMの連携
PostfixはUnix Socketファイルを利用してOpenDKIMと接続を行います。
OpenDKIMは標準では/var/run/opendkim/opendkim.sockをUnix Socketファイルを利用しますが、Ubuntu上でのPostfix SMTPデーモンはchroot環境で動作するため/var/spool/postfix以下でないと接続ができません。
そのため、OpenDKIMのUNIX Socketファイルの配置を変更します。
OpenDKIM UNIX Socketファイル設置用ディレクトリの作成
/var/spool以下にOpenDKIM用ディレクトリを作成します
OpenDKIMとPostfix両方のプロセスからアクセスできるよう所有者をユーザopendkim/グループpostfixとして調整します。
# mkdir /var/spool/postfix/opendkim
# chown opendkim:postfix /var/spool/postfix/opendkim
OpenDKIM設定変更
/etc/opendkim.conf修正
# vim /etc/opendkim.conf
UNIX Socketに関する記述を変更します
| #Socket local:/run/opendkim/opendkim.sock Socket local:/var/spool/postfix/opendkim/opendkim.sock |
/etc/default/opendkim修正
# vim /etc/default/opendkim
UNIX Socketに関する記述を変更します
| #SOCKET=local:$RUNDIR/opendkim.sock SOCKET="local:/var/spool/postfix/opendkim/opendkim.sock" |
Postfix設定変更
/etc/postfix/main.cf修正
# vim /etc/postfix/main.cf
末尾にMilter（Mail Filter）としてOpenDKIMを利用するよう設定を追加します
| # Milter configuration milter_default_action = accept milter_protocol = 6 smtpd_milters = local:opendkim/opendkim.sock non_smtpd_milters = $smtpd_milters |
Postfix SMTPデーモンは/var/spool/postfixにchrootして動作するため、milterの指定先はchroot先以下でopendkim/opendkim.sockを指定します。
各パラメータの説明は以下の通りです
milter_default_action (default:tempail)
Milter (メールフィルタ) アプリケーションが使えなかったり設定が間違えているときのデフォルトの動作を指定
accept（フィルタを利用せず次処理に進む）、reject（メールを拒否）、tempfail（一時エラーで拒否）
milter_protocol (default:6)
Milter (メールフィルタ) アプリケーションと通信するメールフィルタのプロトコルバージョンとオプションの拡張プロトコル。
フィルタアプリケーションの想定バージョンと合わせる必要があります
smtpd_milters (default:空)
Postfix smtpdサーバを通して届いた新しいメールに対する Milter (メールフィルタ) アプリケーションのリスト
non_smtpd_milters (default:空)
Postfix smtpdサーバを通さずに届いた新しいメールに対する Milster (メールフィルタ) アプリケーションのリスト
smtpdを通さずというのは、sendmailコマンドを通じたローカルでのメール送信や、Postfix qmqpdなどを通じたメールなどが該当します
Postfix / OpenDKIM再起動
PostfixとOpenDKIMを再起動して設定を反映します
# systemctl restart postfix opendkim
メール送信テスト
DKIMが適用されているかの最も簡単な方法は、自ドメインからGmail宛にメールを送信します
Gmailで受信したメールの「メッセージのソースを表示 / Show Original」をクリックするとSPFやDKIMのテスト結果が確認できます
このようにPASSと表示されれば無事設定完了が確認できました。
STEP5.ドメイン信頼性向上のためのDMARCセットアップ
DMARC(Sender Policy Framework)とは
DMARC (Domain-based Message Authentication, Reporting, and Conformance)とは、 電子メールにおける送信ドメイン認証技術の一つであり、 RFC 7489*1で標準化されています。
送信ドメイン認証で用いられる技術には、 SPF (Sender Policy Framework)*2やDKIM (DomainKeys Identified Mail)*3があります。 前者のSPFは、送信元メールサーバのIPアドレス等が正当なものかどうかを判別する手段です。 そして後者のDKIMは、メールに電子署名を付加することで、 メールの送信者および内容が改ざんされていないかどうかを検証できるようにするものです。 DMARCは、両者を利用したメールのドメイン認証を補強する技術です。
SPFおよびDKIMを用いて送信元ドメインを認証する際、 認証に失敗したメールをどのように取り扱うかは、受信者の判断に任せられています。 また、認証に失敗したことやそのメールがどのように処理されたかは、 送信者には把握することができません。
そういったSPFおよびDKIMの挙動を補強するために、DMARCが提案されました。 DMARCでは、認証失敗時にどのようにメールを処理すればよいかを、 送信者が受信者に対してポリシーと呼ばれるレコードをDNS上で公開することで表明する仕組みになっています。 受信者は認証に失敗した場合に送信者のポリシーを参照し、 それに基づいてメールをどのように取り扱うかを決定します。
さらにDMARCでは、受信者から送信者に対して認証に失敗した旨を通知するレポートを送ることができます。 送信者は受信者から送られてきたレポートの内容を調べることで、 自身のメールシステムが正しく運用されているかどうかの判断や、 迷惑メール対策などに役立てることができます。
*1 RFC7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
https://tools.ietf.org/html/rfc7489
*2 RFC7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,Version 1
https://tools.ietf.org/html/rfc7208
*3 RFC6376: DomainKeys Identified Mail (DKIM) Signatures
https://tools.ietf.org/html/rfc6376
■参考
dmarc.org
https://dmarc.org/
インターネット用語1分解説～SPFとは～
https://www.nic.ad.jp/ja/basics/terms/spf.html
インターネット用語1分解説～DKIMとは～
https://www.nic.ad.jp/ja/basics/terms/dkim.html
DMARCのセットアップ
DMARCではDNSにDMARCレコードを追加します
設定対象のドメインに下記用のようなTXTレコードを追加します
| ;DMARC Record _dmarc 300 IN TXT "v=DMARC1; p=none; pct=100; fo=1; rua=mailto:dmarc-reports@your-domain.com; ruf=mailto:dmarc-reports@your-domain.com" |
項目の説明（抜粋版）
| 項目 | 説明 |
|---|---|
| v=DMARC1 | プロトコルはDMARC1 |
| p=none |
DMARCチェックに失敗したメッセージを受信サーバがどう扱うべきかを定義 当初はnoneで運用し、問題が無いことが確認でき次第quarantineやrejectに変更することを推奨 |
| pct=100 | DMARCポリシーを適用するメールの割合を指定 例えばpct=100かつp=rejectの場合はDMARCチェックに失敗したメールは全て拒否されます |
| fo=1 |
失敗レポートの送信条件を定義 当初は1で運用し、レポート数を制限したい場合に0に変更を検討することを推奨 |
| rua=mailto:dmarc-reports@your-domain.com | 集約レポートの送信先を定義 URIで記載 |
| ruf=mailto:dmarc-reports@your-domain.com | 失敗レポートの送信先を定義 URIで記載 |
OpenDMARCのインストール
OpenDMARCはDMARCを取り扱うプログラムです
パッケージ（apt）を使ってインストールします
# apt install opendmarc
DBのセットアップは今回はパスします
自ドメインのDMARC登録状況を確認
opemdmarc-checkコマンドを利用して確認します
# opendmarc-check your-domain.com
下記のような登録情報が表示されます
意図した通りの結果になるかを確認します
| DMARC record for your-domain.com: Sample percentage: 100 DKIM alignment: relaxed SPF alignment: relaxed Domain policy: quarantine Subdomain policy: unspecified Aggregate report URIs: mailto:dmarc-reports@your-domain.com Failure report URIs: mailto:dmarc-reports@your-domain.com |
OpenDMARCセットアップ
OpenDMARC設定ファイル編集
設定ファイル/etc/opendmarc.confを編集します
# vim /etc/opendmarc.conf
変更部分を抜粋して記載します。黄色部分が変更箇所です
AuthservID
デフォルトではOpenDMARCはMTAホストネームをAuthserveIDとして利用しますが、そのままでは今後導入するAmavisd-newがOpenDMARCが追加した認証結果ヘッダを上書きしてしまうため、認証サービス用に別名に変更しどのプログラムが追加した認証ヘッダ化を識別できるようにすることをお勧めします。
| ## AuthservID (string) ## defaults to MTA name ## ## Sets the "authserv-id" to use when generating the Authentication-Results: ## header field after verifying a message. If the string "HOSTNAME" is ## provided, the name of the host running the filter (as returned by the ## gethostname(3) function) will be used. # # AuthservID name AuthservID OpenDMARC |
TrustedAuthservIDs
OpenDMARCはTrustedAuthservIDsで指定されたホスト名が記載された認証結果を信頼します。
この設定はOpenDKIMをDKIM認証に利用する際に必要な設定となります。
もしTrustedAuthservIDsをPostfixで指定しているmyhostnameと同一にしない場合、OpenDMARCはOpenDKIMが生成した認証結果ヘッダを無視します。
| ## TrustedAuthservIDs string ## default HOSTNAME ## ## Specifies one or more "authserv-id" values to trust as relaying true ## upstream DKIM and SPF results. The default is to use the name of ## the MTA processing the message. To specify a list, separate each entry ## with a comma. The key word "HOSTNAME" will be replaced by the name of ## the host running the filter as reported by the gethostname(3) function. # # TrustedAuthservIDs HOSTNAME TrustedAuthservIDs mail.your-domain.com |
RejectFailures
デフォルト(false)ではOpenDMARCはDMARCチェックを失敗してもメールをリジェクトしません。
Trueに指定することにより、DMARCポリシーで"p=reject"となっていて、且つDMARCチェックで失敗した際はメールをリジェクトします。
| ## RejectFailures { true | false } ## default "false" ## ## If set, messages will be rejected if they fail the DMARC evaluation, or ## temp-failed if evaluation could not be completed. By default, no message ## will be rejected or temp-failed regardless of the outcome of the DMARC ## evaluation of the message. Instead, an Authentication-Results header ## field will be added. # # RejectFailures false RejectFailures true |
Socket
OpenDMARCはMilter（Mail Filter）として動作します。PostfixはMilterとUNIX Socketファイルを介して通信します。
標準ではOpenDMARCのSocketファイルは/var/run/opendmarc/opendmarc.sockに生成されますが、Postfix SMTPデーモンはchroot環境で動作するため/var/spool/postfix以下でないとアクセスできないため、Socketファイルの生成位置を/var/spool/postfix/opendmarc/opendmarc.sock変更します。
| ## Socket socketspec ## default (none) ## ## Specifies the socket that should be established by the filter to receive ## connections from sendmail(8) in order to provide service. socketspec is ## in one of two forms: local:path, which creates a UNIX domain socket at ## the specified path, or inet:port[@host] or inet6:port[@host] which creates ## a TCP socket on the specified port for the appropriate protocol family. ## If the host is not given as either a hostname or an IP address, the ## socket will be listening on all interfaces. This option is mandatory ## either in the configuration file or on the command line. If an IP ## address is used, it must be enclosed in square brackets. # #Socket local:/var/run/opendmarc/opendmarc.sock Socket local:/var/spool/postfix/opendmarc/opendmarc.sock |
IgnoreAuthenticatedClients
本パラメータを有効(true)にすることにより、SMTP AUTH認証をクリアしたSMTPクライアントはOpenDMARCによるチェック対象外とします。
内部サーバアプリケーションや、ドメインユーザのメールクライアントソフトなどが対象となります。
標準コンフィグに本パラメータは記載がないため、コンフィグファイル末尾に以下を追加
| IgnoreAuthenticatedClients true |
RequireHeaders
本パラメータを有効(true)にすることにより、RFC5322に規定されたメールヘッダ標準に準じないメールはリジェクトします。
例えば、FromヘッダやDateヘッダなどが無いメールはリジェクトされます。またFromヘッダにドメインが含まれないようなものもリジェクト対象です。
標準コンフィグに本パラメータは記載がないため、コンフィグファイル末尾に以下を追加
| RequiredHeaders true |
SPFSelfValidate
本パラメータを有効(true)にすることにより、メッセージヘッダにSPFチェックの結果が無い場合はOpenDMARC自身がSPFチェックを行います
標準コンフィグに本パラメータは記載がないため、コンフィグファイル末尾に以下を追加
| SPFSelfValidate true |
UNIX Socketファイル用ディレクトリ作成
ディレクトリ/var/spool/postfix/opendmarcを作成し、所有者をopendmarc/opendmarcとします。
Postfix SMTPデーモンがアクセスできるよう、ユーザpostfixをグループopendmarcに追加します。
# mkdir -p /var/spool/postfix/opendmarc
# chown -R opendmarc:opendmarc /var/spool/postfix/opendmarc
# chmod 750 -R /var/spool/postfix/opendmarc
# gpasswd -a postfix opendmarc
Postfix設定変更
main.cfを編集します
# vim /etc/postfix/main.cf
パラメータsmtpd_miltersに赤字部分を追加します
| # Milter configuration milter_default_action = accept milter_protocol = 6 smtpd_milters = local:opendkim/opendkim.sock,local:opendmarc/opendmarc.sock non_smtpd_milters = $smtpd_milters |
OpenDMARCへIPアドレスベースホワイトリスト導入
OpenDMARCへはIPアドレスベースのホワイトリストを導入することが可能です。
OpenDMARC設定ファイル/etc/opendmarc.confを編集
# vim /etc/opendmarc.conf
IgnoreHostsパラメータでDMARCチェック対象外とするホストを指定可能です
サンプルでは、127.0.0.1と11.22.33.44を対象とします
| 127.0.0.1 11.22.33.44 |
設定反映
PostfixとOpenDMARCを再起動して構成を反映させます
# systemctl restart postfix opendmarc
確認方法
外部送信メールの確認
対象ドメインのメールサーバより、外部（例えばGmail）へメールを送信します
受信サーバでDMARCチェックがされていれば、下記のようなヘッダが追加されます（例：Gmailで付与されたヘッダ）
| Authentication-Results: mx.google.com; dkim=pass header.i=@your-domain.com header.s=default header.b=qMYgtOUv; spf=pass (google.com: domain of name@your-domain.com designates 11.22.33.44 as permitted sender) smtp.mailfrom=name@your-domain.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=your-domain.com |
Gmailで受信したメールの「メッセージのソースを表示 / Show Original」をクリックするとSPFやDKIM、DMARCのテスト結果が確認できます
受信メールの確認
PostfixのMilter（Mail Filter）でDMARCチェックが行われているか確認を行います。
外部のメールアドレスから該当ドメイン宛にテストメールを送付し、受信メールのヘッダを確認します。
下記のようなヘッダが追加されていれば、OpenDMARCによるチェックがされていることが確認できます。
| Authentication-Results: OpenDMARC; dmarc=pass (p=none dis=none) header.from=hoge.com Authentication-Results: OpenDMARC; spf=pass smtp.mailfrom=hoge@hoge.com |
今回は、SPF/DKIM/Dmarcを使った送信メールの信頼度向上と、受信メールのフィルター実装を進めました。
次回は、Postfixの機能や、SpamAssasinを使ったスパムメール対策の実装を進めます。
