迷惑メール対策（SPAM対策）

1.迷惑メール（SPAMメール）について

(1)なぜ問題があるのか？

　SPAMとは、SPAMと連呼するCMが名前の由来です。そのCMのように「しつこい」ことからSPAMメールと呼ぶようになりました。
　SPAMメール＝迷惑メールという言葉と同義と考えてよいでしょう。
以下に、SPAMによる被害を整理します。
■SPAMによる被害
・回線帯域の圧迫、サーバのキャパシティを使用
・メールの遅延
・セキュリティ被害（SPAMメールに埋め込まれたウイルスへの感染やフィッシング詐欺）
・対策コストの発生
・正常メールの見逃し

SPAMメールはほおっておいていいというものではありません。
業務であれば、明らかに業務効率が起きますし、ウイルス感染による情報漏えいの可能性もあります。対策をとるようにしましょう。

SPAMメールがひどいと言う人がいますが、
そんなに来るんですか？
私のところには全く来ませんよ。

メールアドレスを公開していたり、ドメインの管理者はWHOISのデータベースに登録されているから、そういう人にはたくさんくる。
SPAMメールに関して、IPAのサイトより記述があるので引用する。

SPAMメールに関する記述（IPAサイト）
・メール全体に占めるスパムメールの割合は、調査方法によるばらつきがあるものの、おおよそ70%～95%程度 ・多くのスパムメールがボットネットによって配信されている ・国内では大手携帯電話会社が相次いで、送信ドメイン認証の技術であるSPF（Sender Policy Framework）やSenderID に対応し、国内ドメインにおける同方式の普及率が大幅に向上した。 （以下のサイトより引用（旧リンク）http://www.ipa.go.jp/security/vuln/documents/10threats2008.pdf

(2)電子メールの改ざんは可能か

知らない人アドレスからメールが届く。SPAMメールかと思いきや……
「メールアドレス変えたから登録お願いします　聡子」
なんだ、聡子がメールアドレス変えたんだ。登録しておこう。ん？？
本当に聡子からという確証はまったくないわね。

その通り。本人に電話で確かめるのがベスト。電話じゃなくても、SMSやSNSなどで本当かを確認するといい。
さて、メールの偽装に関する問題。

過去問（H19NW午前 問50）
問50　迷惑メールのメールヘッダから送信元又は中継元のISP又は組織を特定する手がかりのうち、最も信頼できるものはどれか。 -------　ここから　------- Return-Path:<ユーザ名＠ホスト・ドメイン名①> Received:from ホスト・ドメイン名②(ホスト・ドメイン名③［IPアドレス］)     by 受信メールサーバ名 with SMTP id ･･･ From:<ユーザ名＠ホスト・ドメイン名④> ア　SMTPのMAIL FROMコマンドで通知されたホスト・ドメイン名① イ　SMTPのHELOコマンドで通知されたホスト・ドメイン名② ウ　送信又は中継元のIPアドレスから逆引きされたホスト・ドメイン名③及びIPアドレス エ　電子メールのFromヘッダに設定されたホスト・ドメイン名④ -------　ここまで　-------

問題の正解を理解するのと同時に、メールのヘッダについても理解しよう。
この問題には、ヘッダの解説がされているため、一つ一つ理解するとよい。
ヘッダの説明に関しては、以下サイトを参照いただきたい。
電子メール 2.電子メールのヘッダ - ネットワークスペシャリスト - SE娘の剣 -
↓
↓
↓
↓
↓
電子メールのヘッダに関する情報は、H20SV午前1問1に記載されていますので、解いてみてください。今回の正解は、ウ。

2.SPAM（迷惑）メール対策

(0)全体像

迷惑メール対策にはいくつかの技術がある。主な対策を、以下に整理する。

対策箇所	解説	対策技術例
(1)送信メールサーバ	ユーザを認証することで、不正なメールを送らせない （想定としては、社内PCに感染したマルウェアや、悪意のある社員が送信する）	①SMTP-AUTH ②POP before SMTP
(2)プロバイダ	プロバイダ内で、不正なメール通信を拒否する	OP25B
(3)SPAM対策機	メールのヘッダや本文を解析してSPAMメールをブロックする	ブラックリストなど
(4)受信メールサーバ	送信者認証により、SPAMメールを受け取らない	送信元ドメイン認証 (a)IPアドレスによる認証 SPF、SenderID (b)電子署名による認証 DKIM、DomainKeys (c)プラスアルファ DMARC

では、個別にみていこう。

(1)POP before SMTP と　SMTP-AUTH

SPAM対策であったり、社内から不正にメールを送らせない仕組みとして、POP before SMTP や　SMTP-AUTHがある。
次の問題を解いてみよう。

過去問（H23SC春午前2問5）
SMTPサーバに電子メールを送信する前に、電子メールを受信し、その際にパスワード認証が行われたクライアントのIPアドレスに対して、一定時間だけ電子メールの送信を許可する仕組みは何か。

↓
↓
↓
↓
↓
メールのセキュリティ対策に関しては、いろいろな用語がある。午前はマークだからいいが、午後は記述式なので、きちんとスペルを含めて書けるようにしよう。
答えは「POP before SMTP」

過去問（H23SC春午前2問5）
クライアントがSMTPサーバにアクセスしたときに利用者認証を行い、許可された利用者だけから電子メールを受け付ける仕組みは何か。

↓
↓
↓
↓
↓
さきほどと同様に、午後は記述式なので、きちんとスペルを含めて書けるようにしよう。
答えは「SMTP-AUTH」
AUTHはAuthentication（認証）のことである。

もう一問解いてみよう。

過去問（H20SV春午後1問1）

Y主任：まず，当社から送信される迷惑メールを止めなければなりません。迷惑メールの送信には，ポット自身がメール送信機能をもっていて，直接外部のメールサーバに送信する場合と，DMZ上のメールサーバを利用して送信する場合とがあります。 X君：前者に対しては,FWの制御ルールに,図3に示す新たな制御ルールを追加することにします。後者に対しては，メールサーバに[　b　]又は[　c　]のいずれかの方式を適用します。これらの対策は，PCに保存されているメールサーバのアカウント情報を盗用しないポットには有効です。 Y主任：[　b　]1方式には社内PCのメールソフトが対応していません。PCのメールソフトが対応していなくても利用できる[　c　]方式を適用してください。 設問2 (2)本文中の[　b　]，[　c　]に入れる適切な方式を解答群の中から選び，記号で答えよ。また，それぞれの方式の仕組みを，35字以内で述べよ。 解答群 ア　DomainKeys　　　　　　　　　イ　POP before SMTP ウ　Sender Policy Framework　　　エ　SMTP AUTH

ポイントは、メールソフトが対応しているかいないかである。どんなメールソフトが使っているかが書いていないが、それは関係ない。
POP before SMTPは、メールソフトに全く依存しないサーバ側の仕組みだからだ。
↓
↓
↓
↓
↓
解答例
(2)
b　 方式　エ
　　仕組み　メール送信時に,パスワードによる認証が行われる。
c　 方式　イ
　　仕組み　POP認証が成功した後の一定時間内だけメールの送信が可能になる。

(2)OP25B（Outbound Port 25 Blocking）

OP25B(Outbound Port 25 Blocking）とは、直訳の通り、外部へのSMTP（25）通信をブロックする（実際には、プロバイダのファイアウォールでブロックしていることでしょう）。これにより、不正メールを防止する。

過去問では以下のように述べられている。

メールセキュリティ対策（H22SC春午前Ⅱ問15）
「ISP管理下の動的IPアドレスからの電子メール送信について、管理外ネットワークのメールサーバへのSMTPを禁止する」

実際に実行しているのはプロバイダであり、この仕組みを導入したプロバイダは、利用者にその案内を送っていることであろう。
　内部のセグメントから外部へのSMTP（25番ポート）通信を拒否するのであるが、内部のセグメントからのSMTPは、プロバイダのメールサーバからのSMTP通信のみで十分との判断からである。
　ボットネットによる被害が広がる中、自プロバイダ内の感染したPCから外部へのSPAMメールなどを防ぐ狙いである。

プロバイダ外のメールサーバに送りたい場合は、サブミッションポート587を利用しする。ただし、SMTP AUTHを利用する必要がある。

私はプロバイダからの案内を無視して使ってます。しかもつかえています。また、587ポートを使えば、SPAMメールも送れますよね。

この点に関しての解説は、以下を参照ください。

Question(1)
プロバイダから、OP25Bに関する案内が来ていて、サブミッションポートを使う設定が書いてありましたが、まだ変更していません。つまり、送信ポート番号は25のままです が、メールの送信ができます。なぜでしょうか。

↓
↓
↓
↓
↓
Ansewer(1)
プロバイダのメールサーバに送る場合は、サブミッションポートを使う必要はなく、25番ポートにて、そのまま利用できる。一方、プロバイダ外のクラウドサービスのメールサーバに送信する場合は、サブミッションポート587を使ったSMTP AUTHを利用しないと送信できない。
※Submissionとは「提出」という意味であり、サブミッションポートとは、メール送信用のポート番号と考えればよい。

Question(2)
25番ポートを禁止しても、代わりに587番ポートで通信ができるのであれば、587番ポートを使って迷惑メールを送信するだけである。であれば、あまり意味がないのでは？

↓
↓
↓
↓
↓
Ansewer(2)
25番ポートでは認証機能が無かったが、587番ポートでは認証をするということがポイントである。迷惑メールの多くは、ウイルスやボットネットに感染したPCから勝手に迷惑メールを送る。しかし、認証がかかっていれば送信が拒否される。また、仮にSMTP AUTHを使って大量に迷惑メールを送る者がいたら、そのアカウントは不正な者として、プロバイダ側でメールを制限する対策を打つことができる。

Question(3)
であれば面倒なことをせずに、いっそのことOBだけでなく、すべての25番ポートを禁止したら？

↓
↓
↓
↓
↓
Ansewer(3)
Q1にあるように、既存の正規ユーザが、設定を変更せずに利用できるようにするためである。また、そこまでしなくても、十分な迷惑メール対策となるからでもある。

Question(4)
となると、自社でメールサーバを立てる場合には、通常のSMTP通信ができない、つまりメールを送れないのか？

↓
↓
↓
↓
↓
Ansewer(4)
その可能性はある。その場合、プロバイダのメールサーバに対してサブミッションポートで送信するしかない。ただ、OP25Bは、そのプロバイダ内の固定IPからの通信は規制されないことが一般的。

(3)迷惑メールの検知手法

まずは情報処理安全確保支援士の過去問（H25SC秋午前2問14）を見てみよう

過去問（H25SC秋午前2問14）
問13　迷惑メールの検知手法であるベイジアンフィルタリングの説明はどれか。 ア　信頼できるメール送信元を許可リストに登録しておき，許可リストにないメール送信元からの電子メールは迷惑メールと判定する。 イ　電子メールが正規のメールサーバから送信されていることを検証し，迷惑メールであるかどうかを判定する。 ウ　電子メールの第三者中継を許可しているメールサーバを登録したデータペースに掲載されている情報を基に，迷惑メールであるかどうかを判定する。 エ　利用者が振り分けた迷惑メールから特徴を学習し，迷惑メールであるかどうかを統計的に解析して判定する。

これにより、迷惑メールの検知手法を整理しよう

❶ホワイトリスト方式
アの「信頼できるメール送信元を許可リストに登録しておき，許可リストにないメール送信元からの電子メールは迷惑メールと判定する」

❷ブラックリスト方式
RBL（Realtime BlackList）と言われるものである。
選択肢ウの「電子メールの第三者中継を許可しているメールサーバを登録したデータペースに掲載されている情報を基に，迷惑メールであるかどうかを判定する」

❸ベイジアンフィルタリング
選択肢エの「利用者が振り分けた迷惑メールから特徴を学習し，迷惑メールであるかどうかを統計的に解析して判定する」
ベイジアン（bayesian）とは、統計学で有名な数学者である「ベイズの」という意味である。
ちなみに、選択肢イの「電子メールが正規のメールサーバから送信されていることを検証し，迷惑メールであるかどうかを判定する」は、次に解説するSPFやDKIMによる送信ドメイン認証である。

3.送信ドメイン認証

送信ドメイン認証は情報処理安全確保支援士試験で特に重要なので、詳しく解説します。
まず、「送信ドメイン認証」とは何か。メール送信者が、ドメインの所有者であるかを認証することです。SPFにしてもDKIMにしても、DNSを使ってTXTレコードを確認します。その情報をもとに、SPFでは送信元IPアドレスを確認し、DKIMではデジタル署名を検証します。

(1)SPF（Sender Policy Framework）

SPFに関して過去問（H28NW午後Ⅰ問1）では、「送信メールサーバの正当性（当該ドメインの真正のメールサーバであること）を、受信メールサーバ側で確認する方式」と述べられています。
※この過去問に、SPFに関する深い問題があります。お時間あるときにチャレンジしてください。

❶仕組み
SPF（Sender Policy Framework）とは、DNSのゾーンファイルにSPFレコードを追加し、メールサーバにてそのSPFレコードに含まれるIPアドレスを確認することで、ドメイン情報が詐称されていないかを判断します。Senderという言葉が含まれているように、送り主（Sender）側での設定が必要である。

ゾーンファイル
$ORIGIN viva-musen.net.  　 IN  　MX　 　10　　 mail.xxxxxx.com. 　←メールサーバのFQDNを指定   　IN　  TXT　 "v=spf1 ip4:1.1.x.101  ~all"　←IPアドレスを指定

この（2行目）の意味であるが、@viva-musen.netのメールは、1.1.x.101のIPアドレスからしか来ないという意味だ。なので、@viva-musen.netのメールを受け取ったメールサーバは、viva-musen.netをDNSサーバに問い合わせ、TXTレコードから1.1.x.101というIPアドレスを知る。もし、そのメールが違うIPアドレスから来たら、嘘だと判断できる。

SPFはEnvelope-Fromを使ってドメイン認証を行います。
SPFでは、メールアドレスが正しいかまではできない。あくまでもメールサーバの認証なので、ドメインまでです。
※DKIMはHeader-Fromを使ったドメイン認証です。

❷SPFによるドメイン検証の流れ
SPFでドメインを検証する流れを以下の図で解説します。
以下の図を見てください。左側がメールの送信者で、右側がメールの受信者です。
・user1@seeeko.comというメールアドレスを持つ送信者がメールを送ります（下図①）。
・次に、送信者側のメールサーバ（IPアドレスは203.0.113.1）が、受信者側のメールサーバにメールを送信します（下図②）。
・メール受信側では、このメールがドメイン詐称されたものでないかを確認するために、SPFの仕組みを使います。具体的には、受信したメールアドレスである seeeko.comドメインのDNSサーバに，TXTレコードを問い合わせます（下図③）。
・TXTレコードには、seeeko.comドメインの送信メールサーバのIPアドレス（203.0.113.1）が記載されてあり、それを返します（下図④）。

TXTレコードに記されたIPアドレスが，届いたメールの送信元IPアドレスと一致すれば、ドメインが詐称されていないと判断できます。メール受信者はこのメールを受信します。（図⑤）
※メールは複数のメールサーバを中継して届くので、Receivedのメールサーバの経路を確認していることでしょう。

❸SFPの設定
SPFを機能させるには、メール送信側と受信側のそれぞれで設定が必要です。
①メール送信側：DNSサーバにTXTレコードを追加する。
②メール受信側：メールサーバをSPF対応にする（送信したメールサーバにTXTレコードを問い合わせ、結果をもとにメールをどうするかという動作をするため）

・DNSのSPFレコードの構文
最初の v は、バージョンを表す。v=spf1とは、SPFのバージョン1であることを指している。それ以降はFWのルールと同じで、許可するもの、拒否するものを横に並べている。それだけだ。
たとえば、以下を見よう。

1. が許可、-が拒否

なので、この場合、1.1.x.101と1.1.x.102を許可し、それ以外のIPからは拒否する。
結構単純だ。
では、実際にGoogleを見てみよう。

・SPFの実際の設定
みなさんも試していただきたい。ご自身のパソコンからnslookupを起動する。

SPFの実際の設定（nslookup起動）
C:\>nslookup （中略） > set type=txt　←txtレコードを指定 > google.co.jp　←google.co.jpのtxtを確認 （中略） 権限のない回答: google.co.jp    text =         "v=spf1 -all"　←SPFのレコード

最後の「-all」は、すべてNO。つまり、@google.co.jpというメールは一切来ないという意味。
そうだった。googleのメールはgmail.comだ。
では、gmail.comを見てみると、google.comに転送されていたので、google.comを確認する。

google.com確認
> google.com （中略） 権限のない回答: google.com      text =         "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"

inludeしているのもあるが、216.73.93.70/31や216.73.93.72/31のIPアドレスでメールが来ることが分かる。

　でも、構文が違いませんか？
×　ip4:216.73.93.70/31
○　+ip4:216.73.93.70/31
×　~all
○　-all

そうだね。
+は省略できるので、どちらでもいい。省略する方が普通かもしれない。
~　と　-　は違いがある。

記号	内容	補足	アクション
+	Pass	成功	メールを許可
（無し）	Pass	＋と同じ	＋と同じ
–	Fail	明確に失敗	メールを拒否すべき
~	SoftFail	失敗（Fail)とニュートラル（Neutral)の間	メールは拒否しないでほしい

以下で補足する。

構文	意味
v=spf1 ip4:192.168.1.1 -all	192.168.1.1が送信メールサーバのIPアドレス。-allによって、それ以外のIPアドレスは拒否する
v=spf1 ip4:192.168.1.1 ~all	192.168.1.1が送信メールサーバのIPアドレス。~allによって、それ以外のIPアドレスは正規のメールサーバではないが、拒否しないでほしい

「~」が拒否しないでほしいというのは、何かの状態により、TXTレコード以外からのメールが届く可能性があるかもしれないというメッセージだ。

どんな場合にそんなことが起きますか？

たとえば、Aアドレスに届いたメールをBアドレスに自動転送するような場合や、古い仕組みのメーリングリストで送った場合などに、失敗する可能性があります。
※以降は余談なので、適当に流してください。ただし、最近のメーリングリストでは、SPFは失敗しないだろう。なぜなら、エラーメールは送信者ではなく、メーリングリストの管理者に送るように設定するからである。余談が長くなるが、エンベロープFromの情報は、メールヘッダではReturn-Pathに記載される。古いメーリングリストなどでは、メールを転送（送信者→送信者のメールサーバ→メーリングリストのメールサーバ→宛先）する際に、Return-Pathは送信者のままとしていた。すると、宛先からすると、エンベロープFromは送信者のドメインであり、実際に送られてくるのはメーリングリストのサーバからなので、SPFに失敗する。今では、エンベロープFrom（つまりメールヘッダではReturn-Path）には、メーリングリストの管理者に設定することが多いので、SPFは失敗しない可能性が高い。

参考までに、IPAは-allで制限している。sofbankなどの企業は~all

参考（IPA，sofbankなどの企業）

> set type=txt > ipa.go.jp サーバー: xxxx 権限のない回答: ipa.go.jp       text = "v=spf1 mx ip4:192.218.88.1 ip4:192.218.88.4 ip4:192.218.88.231 ip4:202.176.10.23 ip4:202.229.63.234 ip4:202.229.63.238 ip4:202.229.63.243 ip4:210.168.45.67 ip4:133.163.199.192/28 -all" > softbank.jp サーバー: xxxx 権限のない回答: softbank.jp     text = "v=spf1 a mx ip4:52.9.170.29 ip4:52.9.169.194 ip4:52.77.95.65 ip4:52.77.95.163 ip4:52.68.123.180 ip4:52.192.84.201 ~all"

❹SPFの認証の失敗 

SPFを有効にすると、SPFを設定していない会社からのメールが届かなくなりませんか？

受信側の設定次第です。
SPF認証の失敗には大きく2つあります。

結果	内容	補足
Fail	認証失敗	送信元IPアドレスが、TXTレコードの情報と違う場合です。こちらは、拒否してもいいかもしれません。（ただ、SPFの精度は100%ではないので注意が必要）
None	SPF設定無し	送信側がSPFを設定していない場合です。この場合、送信元偽装をしていない場合もあるので、そのメールを拒否するのは慎重になるべきです。

❺SPFはドメインの逆引きと同じでは？

SPFを使わなくても、普通のAレコードではだめなの？
ドメイン名を逆引きすれば、SPFと同じことができるのでは？

鋭いね。成子ちゃんが言っているのは、こういうことだよね。
@viva-musen.netドメインのメールが2.2.X.1のIPアドレスから来たとする。
2.2.X.1のDNSの逆引きをして、viva-musen.netのMXレコードのIPアドレスと一致するかを確認するんだね。

[viva-musen.netのDNS設定]  
   IN MX 10 mx.viva-musen.net  
mx IN A 1.1.x.1

しかし、厳密に言うと、このMXレコードは受信用のメールサーバだ。@viva-musen.netのメールをどのサーバに送ればいいのかをDNS情報として公開している。
@viva-musen.netのメールを送信するサーバの指定は、SPFが正式ということである。

なるほど。わかりました。
じゃあ、逆引きはいったい何をしているんですか？

一般的な逆引きというのは、「逆引き設定がされるかどうか」であろう。SPAM業者であれば、逆引き設定をしていないのが多い（だろう）ということに基づく結果だ。
Postfixの設定で言う　reject_unknown_client　だ。
それ以外には、SPAM対策機器の実装にもよるだろうが、逆引きしたドメインが部分一致するかを見ているものもあるだろう。viva-musen.netからのメールであれば、そのIPアドレスを逆引きして、MXレコードやSPFレコードでなかったとしても、viva-musen.netのドメインであれば、正しいと判断する。

❺（余談）SPFとSenderID

SPFとSenderIDの違いは何か？

どちらも送信元のドメインからIPアドレスを問い合わせ、実際の送信元IPアドレスと同じかをチェックするところは一緒です。
では、一緒？

違いは、ドメイン名の確認をエンベローブで判断するのがSPF、メールヘッダで判断するのがSenderIDである。
メールヘッダとエンベローブの説明については、以下を確認してほしい。
電子メール （7.メールのエンベローブ、ヘッダ） - ネットワークスペシャリスト - SE娘の剣 -

メールヘッダの偽装はメーラで簡単にできるから、
SPFの方が有効な対策なのかな？

いや、不正な第三者からしたら、どちらも簡単だ。
強いて違いを言うのであれば、メール本文が送られてくる前のエンベローブの段階でチェックできるSPFの方が効率的だと思う。

以下の問題を見てみよう。

過去問（H22秋SC午前2問12）
問12　送信元を詐称した電子メールを拒否するために、SPF（Sender Policy Framework)の仕組みにおいて受信側が行うことはどれか ア　Resent-Sender:, Resent-From:, Sender:, From:などのメールヘッダ情報の送信者メールアドレスを基に送信メールアカウントを検証する。 イ　SMTPが利用するポート番号25の通信を拒否する。 ウ　SMTP通信中にやり取りされるMAIL FROMコマンドで与えられた送信ドメインと送信サーバのIPアドレスの適合性を検証する。 エ　付加されたディジタル署名を受信側が検証する。

↓
↓
↓
↓
↓
ウがSPFで、アがSenderIDの説明です。
ちなみに、イはOP25Bで、エはDKIM(DomainKeys Identified Mail)

❻過去問
・過去問事例1
情報処理安全確保支援士の過去問（H22SC春午後Ⅱ問1設問3(2)）では、SPFを設定したTXTレコードの書き方について問われている。
なので、書き方も理解しておいたほうがいいだろう。

SPFを設定したTXTレコードの書き方（H22SC春午後Ⅱ問1設問3(2)）
(2)本文中の下線③について,カタログWebサーバのドメイン名に対して, SPFを設定したTXTレコードを解答群から一つ選び,記号で答えよ。 解答群 ア　catalog.y-sha.co.jp. IN TXT “v=spf1 +ip4:x1.y1.z1.2 -all” イ　catalog.y-sha.co.jp. IN TXT “v=spf1 +ip4:x1.y1.z1.4 -all” ウ　catalog.y-sha.co.jp. IN TXT “v=spf1 +ip4:x1.y1.z1.5 -all” エ　catalog.y-sha.co.jp. IN TXT “v=spf1 +ip4:x1.y1.z1.6 -all” オ　catalog.y-sha.co.jp. IN TXT "v=spfl -all"

・過去問事例2
H26NW午後Ⅱ問1では、SPFによる認証処理の概要が記載されている


ぜひ、問題にチャレンジしてほしい。

(2)DKIM(DomainKeys Identified Mail)

❶概要

過去問（H22春SC午前2問14）
「送信側メールサーバでディジタル署名を電子メールのヘッダに付与して、受信側メールサーバで検証する」ものは何か

これもSPAM対策の一つです。
SPAM対策もたくさんあってよくわかりませんね。
SPFやSender IDもありますよね。どう違いますか？

↓
↓
↓
↓
↓
これは、スパムメールの対策であるDKIM(DomainKeys Identified Mail)の説明である。
どちらも送信元のドメインを認証をする点では同じである。
DKIMの特徴は、SPFやSenderIDのようにIPアドレスやメールアドレスで認証するのではなく、証明書を使って認証する点です。

SPFはEnvelope-Fromを使ってドメイン認証を行います。
DKIMはHeader-Fromを使ったドメイン認証です。
注意点として、DKIMはPCは関係なく、メールサーバ間の設定です。

❷DKIMの設定
DKIM（DomainKeys Identified Mail）を設定するには、メールの送信側と受信側で以下の設定を行います。
①メール送信側
・（署名のための）公開鍵と秘密鍵のペアを作成
・外部DNSサーバに公開鍵（TXTレコードを使う）を登録する。
・メールサーバをDKIM対応にする（メールを送信する際に、DKIM-Signatureヘッダにディジタル署名を付与するため）
②メール受信側
・メールサーバをDKIM対応にする
署名をつけて、その署名を確認するという流れは、一般的なPKIと同じです。また、なりすまし防止、改ざん防止ができる点、メールの暗号はしない点もディジタル署名が実現できることと同じです。

実際の設定は、opendkimを使うことになるでしょう。
ここがわかりやすいです。
https://blog.apar.jp/linux/856/

❸メールヘッダとDNSレコード
参考までに、DKIM-Signatureヘッダや「dタグ」の例の実物を見てみましょう。皆さんも、受信したメールのヘッダを開いて確認してください。以下はGmailの例です。

Gmailの例
Return-Path: <@gmail.com> Received: from mx12...or.jp・・・・; Wed, 26 Feb 2020 21:39:48 +0900 Received: from mx...or.jp・・; 26 Feb 2020 21:39:49 +0900 Received: ・・・・ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:・・・・ b=OM9C6mF3fKAxWy23mqPNsbgyWSXas82vl36NOJzHwavBiTIT1hTGM1KixS8glks+gn enToe0BPmtGlikovWC+MU7SmGIYz・・・・

ここで、d=google.comとあるのが、送信ドメイン名です。また、b= OM9C6・・・とあるのが署名です。署名ですから、メールをハッシュしたものを、送信メールサーバの秘密鍵で暗号化しています。
また、試験では問われないでしょうが、h=の部分にて、署名対象のヘッダを記載しています。たとえば、from（送信元メールアドレス）などが対象であることが分かります。正しく署名の検証をするためのものと考えてください。
もう一つ、TXTレコードも確認しておきましょう。確認方法は少し複雑でして、上記にあるs=のセレクタを使います。この言葉を覚える必要はありませんが、セレクタは、複数の公開鍵を区別する識別子と考えてください。DNSのテキストレコードにおいて、[s（セレクタ）の値]._domainkey.[d（ドメイン）の値]のレコードを探します。今回でいうと、s=20161025で、d=gmail.comなので、20161025._domainkey.gmail.com になります。

> 20161025._domainkey.gmail.com  
（中略）  
権限のない回答:  
20161025._domainkey.gmail.com text =  
"k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIi・・・・

このp=で記載されているのが公開鍵です。
PKIの仕組みを使っているので、途中のメールサーバを経由したとしても、送信者を正しく認証できます。SPFに比べて精度が高いと言えるでしょう。

PKIが破られる可能性は無いと思っていいですよね？

はい、確率的にはゼロと言ってもいいでしょう。しかし、だからといって、DKIM認証さえすればいい、というわけではありません。たとえばメーリングリスト宛に送る場合、メールヘッダなどを付け替えることがあり、その場合は署名の検証が失敗します。そういう観点から、DKIMを有効にすれば確実、というものでもありません。また、このあとに記載する作成者署名と第三者署名の点もあります。
ですので、DKIMだえではなく、SPFやDMARCなどとも併用することが望まれます。

❹DKIM認証の流れ
情報処理安全確保支援士の試験の過去問（R1SC秋午後Ⅰ問1）をみて、DKIMの認証の流れをみましょう。

過去問

Ｕ主任：DKIMに対応したメールを送信するためには，まず，準備として公開鍵と秘密鍵のペアを生成し，そのうち公開鍵を当社の外部DNSサーバに登録し，当社の外部メールサーバの設定を変更します。 DKIM利用のシーケンスは，図５及び図６に示すとおりとなります。 　　図5　DKIM利用のシーケンス -------　ここから　------- 1. DKIM-Signatureヘツダにディジタル署名を付与し，メールを送信する。 2.受信側メールサーバは, DKIM-Signatureヘツダのｄタグに指定されたドメイン名を基に，外部DNSサーバに公開鍵を要求する。 3.要求を受けた外部DNSサーバは，登録されている公開鍵を送信する。 4.②受信した公開鍵，並びに署名対象としたメール本文及びメールヘッダを基に生成したハッシュ値を用いて，DKIM-Sienatureヘッダに付与されているディジタル署名を検証する。 　　図6　DKIM利用のシーケンスの説明 -------　ここまで　------- Ｑ部長：DKIMの方が少し複雑なのだな。 Ｕ主任：はい。しかし, DKIMは，メール本文及びメールヘッダを基にディジタル署名を付与するので，転送メールサーバがディジタル署名，及びディジタル署名の基になったメールのデータを変更しなければ，たとえメールが転送された場合でも検証が可能です。 SPFとDKIMは併用できます。

図にすると、以下になります。

これを参考に、DKIMを理解していきましょう。

❺認証結果
DKIMやSPF認証をすると、Authentication-Resultsとして、以下のように結果が表示される。DKIMのヘッダがあっても、このような記載が無い場合は、送信側がDKIMの署名を付けているが、受信側がDKIM署名を確認していない。
　dkim=pass
　spf=pass
　dmarc=pass

以下はgmailでメールを受け取った場合のヘッダの一部

ARC-Authentication-Results: i=1; mx.google.com;  
dkim=pass header.i=@docs.google.com header.s=20210112 header.b=pfQLEtHe;  
spf=pass (google.com: domain of xxx as permitted sender) smtp.mailfrom=xxxxxx;  
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=docs.google.com

❻ 作成者署名と第三者署名
このあたりまでくると、情報処理安全確保支援士の試験では問われないでしょうから、流してもらって構いません。
たとえば、以下のケースでDKIM認証がどうなるか考えてください。

Q.　A社がMicrosoftなどのクラウドサービスB社のメールサービスを使っているとします。その場合、メールを送信するのはB社です。ドメインはA社（asha.example.com)であっても、実際にメールに署名してメールを送信するのは、B社です。このような場合、DKIMの認証はどうなるでしょうか。

↓
↓
↓
↓
↓
A.実はこれ、DKIMの認証は成功します。このような方式を第三者署名と言います。
DKIMにおける署名には、作成者署名と第三者署名の2つがあります。
①作成者署名
メールヘッダにあるメールアドレスのドメインと、署名のドメイン（dタグのドメイン）が同じ場合です。メールのドメインを持つ組織のユーザがメールを作成したことが確認できます。（本来のあるべき姿でしょう）
②第三者署名
上記以外の違うドメインの組織が署名した場合です。DKIMのdタグのドメインを見て、メールの受信者はそのドメインの公開鍵を取得し、メールの検証をします。検証が正しければ、DKIM認証は成功です。

それって、誰でも署名できるってことでは？

はい、その可能性があります。第三者署名の場合、メールを作成した本人がいる組織からのメールであることはわかりません。メールの送信者が、自分を詐称していないかがわかります。先のクラウドサービスでメールを送っている場合、クラウドサービスのサーバから送信されたことが確認できます。
なので、DKIMといえど、なりすましを完全に防げるものでありません。この点は、DMARCを使うと、第三者署名を拒否することができます。（設定するかどうかは、正規のメールが拒否されないかを確認したうえで判断が必要）

❻DKIMに関する確認問題

Q1.DKIMにおいて、作成した秘密鍵と公開鍵はどこに配置するか？ また、その理由は？

↓
↓
↓
↓
↓
A1.
・秘密鍵：メールを送信するメールサーバ
→理由：メールの署名をつけるため

・公開鍵：DNSサーバ
→理由：メールを受信するサーバが公開鍵を取得できるようにするため

Q2.公開鍵を配置するDNSサーバは誰のDNSサーバ？

↓
↓
↓
↓
↓
A2.メールを送信するサーバと同じドメインのDNSサーバ

Q3.DKIMを利用できるようにするには、サーバの設定変更が必要？すべて答えよ。また、その理由も述べよ。

↓
↓
↓
↓
↓
A3.・送信側のメールサーバ
→理由：DKIMに対応させ、メールを署名する処理をするため
・送信側のDNSサーバ
→理由：DNSサーバに公開鍵を登録するため
・受信側のメールサーバ
→理由：DKIMに対応させ、署名を確認する処理をするため

Q4.DNSに登録する公開鍵であるが、何のレコードに登録するか

↓
↓
↓
↓
↓
A4.TXTレコード

Q5.メールに署名をするのは誰？認証局？

↓
↓
↓
↓
↓
A5.メールを送信するメールサーバ 

■余談 DKIMの署名ですが、どうやっているのでしょうか。 やり方は、メールヘッダとメールのボディの両方を署名します。エンベロープの情報は署名の対象外です。 だて、DKIMの署名では、先にメールヘッダとメールボディに関して、正規化という処理をします。これをしておかないと、適切な署名にならない可能性があるからです。 正規化方法には、simple relaxedがあります。メールヘッダ、メール本文のそれぞれで正規化します。メールサーバによっては、途中でスペースを削除するなどの軽微な変換をする。その処理を考慮しないと、DKIMがほとんどエラーになってしまう。 ・simple:厳格で、ヘッダの変更は一切認めない。メッセージボディ（本文）も最後の空白行以外は変更無し ・relaxed：少し緩く、ヘッダにおいて、連続したスペースを1つにするなどを容認します。 デフォルトはsimpleです。 https://www.wareportal.co.jp/manual/mdaemon/security--dkim_options.htm また、DKIMのsimpleとrelaxedは、送信側が決めます。つまり、受信側のサーバで、メールヘッダを変えたりするのであれば、どこでDKIMの確認をするかを検討する必要があります。一般的には、一番外側のMTAでDKIM検査をします。

(3)DMRAC

2023年5月時点で、日経225の140社（62.2%）がDMARCを導入。ただし、p=noneであれば、あまり意味が無い。
https://it.impress.co.jp/articles/-/24844
また、DMARCの報告書。JPCERTによる、具体的な数字が載っている。
https://www.janog.gr.jp/meeting/janog51/wp-content/uploads/2022/12/JANOG51_DMARC_%E5%B9%B3%E5%A1%9A%E3%81%95%E3%82%93-1.pdf

❶DMARCの目的

簡単にいうと送信元ドメイン認証の精度を高めることです。具体的には、精度に関して、大きく2つの観点で精度を高めます。
▼１．誤検知 SPFやDKIMで認証エラーになったものでも、正しいメールが存在する。（メイン機能）
そこで、認証エラーになったメールを、DMARCではさらに、隔離（quarantine）、メールを拒否（reject）受信（none）という3段階で判断ができる。
▼２．見逃し SPFやDKIMですり抜けたメールであっても、詐称されている可能性があり、より詳細な確認を行う。

具体例を挙げてみます。皆さんのところにも、Amazonのドメインを装ったフィッシングメールが届くのではないでしょうか。大手のプロバイダを契約してSPFやDKIMが有効になっていても、これらのフィッシングメールは届きます。
たとえば、SPFは、エンベロープ情報しか見ません。Amazonに詐称したフィッシングメールの場合、（Amazonではなない）独自ドメインXを取得し、そのメールサーバから送信する。この場合、SPF認証が成功する可能性がある。なぜなら、そのドメインxの正規のメールサーバから送信すれば、SPFは正しいと判断するからです。
Amazonなどのフィッシングメールの場合、エンベロープ情報は偽ドメインで、メールヘッダがAmazonである。こうなると、SPFでは検知できない。（DKIM認証でも第三者署名ができるから、不十分な仕組みであることは同じ）。DMARCは追加検証ができるので、メールヘッダのドメインとエンベロープ情報のドメインが一致するかを確認する。こうして、Amazonになりすましたフィッシングメールを確認することができるようになるでしょう。

❷DMARCの処理の流れと機能
DMRAC（ディーマークと読みます。Domain-based Message Authentication, Reporting, and Conformance）は、順番としては、SPFやDKIMで検証が終わってからDMARCの処理が行われます。流れを図にすると、以下になります。

DMARCには3つの機能があります。
①　SPFやDKIMの検証に失敗した場合のアクション（そのまま受信、拒否、隔離）を決める　→受信側がより正確なアクションを行えるための判断材料を与える（上図の内容）
②　DMARC Alignment
Alignmentは、比較という意味で、SPFの場合、Header-FROMとEnvelope-FROMを比較します。表２のaspfやadkimにあるように、メールヘッダと、エンベロープやデジタル署名のドメイン情報を比較します。第三者署名も拒否することができます（拒否するかどうかは別途判断が必要）
※↑の図だと記載が無いですが、SPFやDKIMに成功した後にチェックを行います。
③　認証の結果を送信メールサーバに送信する

3つの中で、②と③はオプション機能で、①が主機能になります。SPFやDKIMの検証に失敗した場合でも、正規なメールである可能性もあります。このメールを、メールを隔離（quarantine）、メールを拒否（reject）するか、または何もせずにそのまま受信（none）するのかを、メール送信者が宣言をします。

送信側ですか？メールを拒否するかの判断は受信側ではないのですか？

DMARCとしては、送信側です。SPFの設定などは送信側が行っていて、たとえば、「うちのDKIMの署名を付与する仕組みは十分な検証が取れています。DKIMでの検証が失敗したら確実になりすましメールなので拒否してください」などという判断基準を提供するのです。もちろん、その情報を受けて、最終判断は受信側で行います。たとえば、p=reject（つまり拒否）であっても、本当に拒否せずに迷惑メールに振り分けてもいい。
DMARCはメールの送信側が決定しますが、利用方法としては、いきなりrejectにはしないことでしょう。正規のメールも拒否される可能性があるからです。しばらくはnoneやquarantineで拒否しない運用して、自社から送るメールが全てDKIMによって適切に署名ができていることを確認できたら、rejectにするなどが現実的だと思います。

❸詳細な仕組みの確認
情報処理安全確保支援士の過去問（R1秋SC午後Ⅰ問1）を見ましょう。

過去問（R1秋SC午後Ⅰ問1）
U主任：DMARCは，メール受信側での，SPFとDKIMを利用した検証，検証したメールの取扱い，及び集計レポートについてのポリシを送信側が表明する方法です。DMARCのポリシの表明は，DNSサーバにTXTレコードを追加することによって行います。TXTレコードに指定するDMARCの主なタグを表2に示します。

※pだけを設定しても、それ以外のaspfなどはデフォルトが設定される。
では、この表を解説します。問題文に「SPFとDKIMを利用した検証，検証したメールの取扱い，及び集計レポート」とあります。この3つが表のどれに該当するかを含めて順に解説します。

①「SPFとDKIMを利用した検証」
　表のaspfとadkimが該当します。SPFやDKIMの片方（または両方）で検証が成功した上で、DMARCでの追加の検証を行います。
※SPFやDKIMで検証がNGとなったものは、改めて検査をすることはなく、次の②「検証したメールの取扱い」の判断に進みます。

aspfは、（SPFの追加というのは少し変ですが、）Envelope-FROMのドメインとHeader-FROMのドメインが一致しているかを確認します。値と説明にあるrとsは、relaxed（緩和：デフォルト）か strict（厳格）かの違いです。sの場合は厳格なので、sub.example.comとexample.comは別と判断します。

adkimは、DKIM-SignatureヘッダのdタグとHeader-FROMのドメインが一致しているかを検査します。rとsは先のaspfと同じです。 

②「検証したメールの取扱い」
　表のpが該当します。すでに述べたように、何もせずにそのまま受信（none）、メールを隔離（quarantine）、メールを拒否（reject）するか、メールの送信者の宣言です。

③「集計レポート」
　表のruaが該当します。rua（Reporting URL for aggregate data）は、集約されたレポートです。ここで指定したメールアドレスに対して、検証の成功や失敗などの集約結果レポートが送られます。メール送信側では、このレポートをもとに、認証結果の分析が行えます。
参考までに、レポートには、❶rua（aggregate report）：統計情報、❷ruf（failure report）：DMARC処理による失敗レポート、の2つがある。rufは基本的には使われていない。ruaでも、DMARCのエラー、エンベロープFROMとHeaderFROMのチェック結果も表示してくれるので、統計としては十分

どんな分析をするのですか？

特に、検証が失敗した原因の分析に活用されることでしょう。たとえば、本物の偽装メールもあれば、一部のシステムからは何らかのクラウドサービスを経由して送信しているケース、設定忘れとして、自社にSPFを設定していないメールサーバがあることなどに気づくことができたりします。メールを送信する側が、p=quarantine（迷惑メールフォルダ）、p=reject（拒否）などの設定をしやすいことでしょう。とはいえ、今のところ、p=noneの会社がほとんどだと思われます。

❹DMARCの設定
DMARCを設定するには、メールの送信側とメールの受信側のそれぞれでの設定が必要です。ただ、大前提として、SPFかDKIMのどちらかを導入する必要があります。片方だけでもいいですし、両方でもいいです。

1)メール送信側
DNSサーバで、TXTレコードを設定します。また、レポートを受け取る設定にした場合、レポートがメールが届きますので、それを受信できるようにします。

2)メール受信側設定
メールサーバをDMARC対応にします。

❺DMARCのDNS設定
DMARCに関しても、nslookupでTXTレコードをみてみましょう。DMARCの情報は、ドメインに「_dmarc」をつけて記載されます。以下は、google.comの情報を確認しています。※gmail.comとは結果が違うので注意

c:\>nslookup  
・・・（略）・・・  
> set type=txt  

> set type=TXT
> _dmarc.google.com

権限のない回答:
_dmarc.google.com       text =

        "v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

v=DMARC1は、DMARCのバージョン１という意味です（今のところバージョン１だけ）。そして、p=rejectとあります。よって、SPFおよびDKIMの検証に失敗したメールは拒否します。

また、rua=mailtoとして、集約レポートの送付先のメールアドレスが記載されています。
■参考資料：フィッシングの現状と対策（2020年後半版）

以下の資料がとても詳しかった。
https://www.janog.gr.jp/meeting/janog47/wp-content/uploads/2020/11/janog47_dmarc_hiratsuka.pdf

4.参考

以下は余談であり、試験には出ないので、参考程度に。

❶受け取ってしまったSPAMメールの対処
迷惑メールを受け取ってしまうことは当然ある。その後の対処であるが、どう対策すればいいのだろうか。
基本的には①URLフィルタリングと②ウイルススキャンである。
なので、UTMや専用装置により、これらを対処する必要がある。SPAM対策はSPAM装置だけで対処するものではないと言える。

	脅威	対策
不正なURL	メールに記載されたURLをクリックすることで、不正サイトへ接続してしまう	URLフィルタリング装置（プロキシサーバに実装されていることも多い）のURLフィルタリグ機能
ウイルス	添付ファイルやメールそのもの（HTML形式）にウイルスが埋め込まれ、それを実行することで感染してしまう。	パソコン（またはゲートウェイ、または迷惑メール対策装置に実装されている）ウイルススキャン機能

❷SPAMメールのバウンスメール
バウンスメール(bounce mail)は、宛先不明などのメールは、その理由とともに発信者に返すというのが仕様。bounceとは、「バウンドする」という意味。
・メールは中継して流れるので、メールサーバは複数存在する。最初に拒否したメールサーバが返す。
・ユーザが存在しない宛先へのSPAMメールに対し、バウンスメールを返すと、メールサーバの負荷が増えたり、メール爆弾としてDoS攻撃になったりする。

対策として、入口のメールサーバで550user unknowdを返す。通常は、外部メールサーバ（MTA）→内部メールサーバである。外部メールサーバがメールを受け取ろうとする段階で、ユーザアカウントが存在するかをチェックし、存在しなければ拒否する。