メインコンテンツに移動

前回は、メールバーチャルホストと管理用の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
spamass-milter 0.4.0
postfix-pcre 3.4.13

ウィルススキャン
(当初導入するも、メモリ不足で無効化)
Amavis 2.11.0
ClamAV 0.103.2

当初、ウィルススキャンとしてAmavis/ClamAVを導入しました。

メモリが2GBでは足りなかったため最終的には無効化していますが、導入手順はメモとして記載しています。
 

今回は、メールサーバ構築に関して理解しながら進めるために、段階的にステップを踏みながら構築を進めていきます。

  1. Postfixサーバの基本セットアップ
  2. TLS暗号化とDovecot IMAP/POP3サーバセットアップ
  3. PostfixAdminを使ってバーチャルメールボックス作成
  4. 信頼度向上のためのSPF/DKIMレコード作成
  5. ドメイン信頼性向上のためのDMARCセットアップ
  6. Postfixでのスパム受信ブロック
  7. SpamAssassinを使ったスパム受信ブロック
  8. AmavisとClamAVを使ったウィルス対策

 

1ページでの記載には大きすぎたので記事を分割します

今回の記事では、信頼度向上に向けてSPF/DKIMレコードの作成、DMARCセットアップとSTEP4とSTEP5を記載します。

 

STEP4.信頼度向上のためのSPF/DKIMレコード作成

SPF (Sender Policy Framework)とは

JPNICからの引用です。

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とは

JPNICからの引用です

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
KeyTable           refile:/etc/opendkim/key.table
SigningTable       refile:/etc/opendkim/signing.table

# Hosts to ignore when verifying signatures
ExternalIgnoreList  /etc/opendkim/trusted.hosts

# A set of internal hosts whose mail should be signed
InternalHosts       /etc/opendkim/trusted.hosts

 

簡単にパラメータの解説をします

Canonicalization (string型)

Canonicalizationディレクティブはメールヘッダ/ボディのフォーマットをどれくらい厳格にするかを指定するポリシーです。

メールは送信経路上で予期せず(勝手に)改変されることがあります。(例:タブを空白に変換)

全く改変を許容しないsimpleと多少の変更は許容するrelaxedがあり、今回はヘッダはrelaxed、ボディはsimpleに指定しています。

Mode (string型)

Modeディレクティブにはs(sign, 署名)とv(verify, 検証)があります。

今回は両方を対応するためsvとしています。

SubDomains (boolean型)

SubDomainsディレクティブはサブドメインの利用有無を指定します。

尚、OpenDKIMではBoolean型は1文字目のみで判定を行います。肯定の場合は”T",”t”、”Y”、”y”、”1”、否定の場合は"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.comfSighningTableディレクティブで指定したファイル/etc/opendkim/signing.tableを作成

# vim /etc/opendkim/signing.table

内容は以下となりますが、ドメイン名は適宜修正ください

*@your-domain.com      default._domainkey.your-domain.com

Key Table作成

opendkim.comfKeyTableディレクティブで指定したファイル/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.comfExternalIgnoreListディレクティブとInternalHostsディレクティブで指定したファイル/etc/opendkim/trusted.tableを作成

# vim /etc/opendkim/trusted.hosts

構成によりますが、今回はメール送受信を行う内部サーバを対象として同一ファイルをExternalIgnoreListInternalHostsで利用しています

127.0.0.1
locahost

*.hs3.org

秘密鍵/公開鍵のキーペア作成

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のテスト結果が確認できます

Image
DKIM Test

このようにPASSと表示されれば無事設定完了が確認できました。

 

 

STEP5.ドメイン信頼性向上のためのDMARCセットアップ

DMARC(Sender Policy Framework)とは

再びJPNICからの引用です

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: 特もせず、違反があった場合はDMARCレコードのmailtoにレポートを送信
quarantine: 隔離をするよう指示
reject: 認証に失敗したメールは無条件に拒否するよう指示

当初はnoneで運用し、問題が無いことが確認でき次第quarantineやrejectに変更することを推奨

pct=100 DMARCポリシーを適用するメールの割合を指定
例えばpct=100かつp=rejectの場合はDMARCチェックに失敗したメールは全て拒否されます
fo=1

失敗レポートの送信条件を定義
0(default): すべての認証がpass出なかった際にレポートを作成
1: いずれかの認証メカニズムで失敗してもレポートを作成
d: DKIMの署名検証が失敗した際にレポートを作成
s: SPFの検証が失敗した際にレポートを生成

当初は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のテスト結果が確認できます

Image
DMARC Test

受信メールの確認

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を使ったスパムメール対策の実装を進めます。