令和6年（2024年）ネスペ午後Ⅱ　問２　解答解説

2026.08.31
  1. 設問１
    1. （１）mail.y-sha.lan
    2. （２）TTLを60秒という短い値に設定している
    3. （３）a: Preference　b: y-mail2　c: 逆引き
    4. （５）メールサーバのFQDNに詐称したメールアドレスのドメイン名を登録する
  2. 設問2
    1. （2）d: SMTP　e: MAIL FROM　f: y-sha.com
  3. 設問３
    1. （３）受信したメールが正規のメールサーバから送信されたものかどうかが分かるから
    2. （1）DNSサーバ名：外部DNSサーバY　登録する情報：メール中継サーバZのIPアドレス
    3. （２）j: y-sha.com
    4. （３）メール中継サーバZから鍵が漏洩しても、Y社で実施中のDKIMの処理は影響を受けない。
    5. （４）なりすましメールもメール中継サーバZから社外に転送されるから
  4. 設問５
    1. （１）　送信者の秘密鍵でハッシュ値を暗号化する
    2. （２）　送信者の公開鍵で署名を復号する
    3. （３）　取り出したハッシュ値と生成した値が一致する
    4. p.3 図３ 社内DNSサーバYが管理するゾーン情報の見方ｰｰｰｰｰｰｰｰｰ
    5. SPF(Sender Policy Framework)とは？——
    6. DKIM(DomainKeys Identified Mail)とは？—–
    7. p.19 Y社の運用ポリシーについて
      1. (あ)　社内メールサーバYには、Y社に勤務する従業員以外のメールボックスは設定しないこと
      2. (い)　社内PCによるメール送受信は、社内メールサーバYを介して行うこと
      3. (う)　メール中継サーバY1及びY2にはメールボックスは設定せず、社内メールサーバYから社外宛て、及び社外から社内メールサーバY宛ての、メールだけを中継すること
      4. (え)　Y社のドメインを利用するメールには、なりすまし防止などの情報セキュリティ対策を講じること
    8. p.20 Z社に委託するメールによるサポート方法
    9. p.21 S/MIMEとは？——
    10. MUA,MAT,MDAとは？—-
    11. 不備により設問５は成立しないとは？—

設問１

（１）mail.y-sha.lan

この問題は社内メールサーバYがどこに転送するかを聞いている。社内メールサーバが外部へ送る際のスマートホストとして、DMZの中継サーバを使用する。
なお、以上の画像の下線②から転送先は１つの固定ではなくラウンドロビンが使われることが分かる。それをベース考えると、図３で同一のFQDNが２つ存在するレコードがある。それがmail.y-sha.lanなので、答えもmail.y-sha.lanになる。

（２）TTLを60秒という短い値に設定している

TTLを短くすることで、使用中のレコードがローテーションしやすくなる。そのため60秒おきに別の中継サーバを使えるようになる可能性が上がる。また、今回の構成で、mail.y-sha.lanの名前解決をするのはほぼ、社内メールサーバしか存在しない。つまり、１つのクライアントしかいないということ。
ということは、結局60秒間はずっと同じ中継メールサーバが使われるということである。
逆を言えば、もし、複数のクライアントがいたら、そもそものDNSラウンドロビンによって分散されるのでTTLをそこまで短くする必要はないし、リアルタイムで並列処理が行われる。

Q.リアルタイム並列処理をするには？
ラウンドロビンを使っても結局、クライアントは社内メールサーバYのみなので、60秒間はずっと同じ中継メールサーバが使われ続けてしまう。なので、一方が遊休に近い状態になってしまう。クライアントが少数でも、この問題を解消しする方法はあるのか。。
A.ロードバランサー（LB）を導入することによって、クライアントが少なくてもリアルタイムで分散処理が可能になる。
手順１：DNSにmail.y-sha.lanのIPアドレスをLBのIPアドレスとしたAレコードを設定する
手順２：内部メールサーバYが名前解決により、LBに転送する
手順３：LBが配下の中継メールサーバのリアルタイム情報から、適切な方へ転送する

（３）a: Preference　b: y-mail2　c: 逆引き

a:Preference
　優先度やPriorityと書かれることもたまにあるが、正式にはPreferenceが正しい。

b: y-mail2
　MXレコードはPreferenceが小さい方が優先度が高くなる。このことより、Preferenceが1であるy-mail2が正解である。

c: 逆引き
　逆引き（ReverseLookUP）とはIPアドレスからホスト名を導くことである。これを使うと送信元認証に使えるが、弱点もある。では、逆引きのフローを見ていこう！

▼グローバルIP 200.100.50.1を逆引きする場合
１．逆引きアドレスを作成しDNSに問い合わせる
　オクテット単位で分割し、順番を逆にした値（200.100.50.1→1.50.100.200）の後ろに、in-addr.arpa.をつける。＝（1.50.100.200.in-addr.arpa.)
２．DNSがその名前を辿る
　DNSサーバはin-addr.arpa.の世界から順に、その名前が登録されているPTRレコードを探す。
３．ホスト名が返ってくる
　DNSから「そのIPのホスト名はmail.example.comだよ」と返ってくる

ShellScript
#PTRレコード
1.50.100.200.in-addr.arpa.   IN   PTR   mail.y-sha.com.

４．一致チェック
　メールの差出人アドレスのドメインとDNSから教えてもらったホスト名のドメインが一致するかを確かめる。

（５）メールサーバのFQDNに詐称したメールアドレスのドメイン名を登録する

この問題では、逆引きにフォーカスが当てられているが、正引きでも同じ現象は起こる。管理者であればDNSレコードは偽れるという弱点で見ると正引きも逆引きも同じ弱点を抱えている。では、逆引きがどのように詐称するのかを見ていこう！

▼逆引きの詐称方法と効果
１．200.100.50.1に対するPTRレコードを準備する
　＊グローバルIP200.100.50.1を保持する管理者が、自身が管理するDNSサーバ（atteker.evil.com.)にホスト名を詐称したレコードを追加する

ShellScript
#PTRレコード
1.50.100.200.in-addr.arpa.   IN   PTR   mail.gmail.com.

２．攻撃者は偽のメールを送信する
　偽のメールは、送信元を1で偽造したホスト名のドメインと同一のドメインにして送信する。（xxxxx@gmail.com)
３．受信者は逆引きで正当性を確かめる
　送信元のIPアドレスを逆引きしていくと、攻撃者のDNSまでたどり着き、そこからPTRレコードを取得する。すると、ホスト名がmail.gmail.com.であることが分かる。そのドメインとメール送信元のドメインxxxxx@gmail.comが同じなので整合性があると誤った判断をしてしまう。

設問2

（2）d: SMTP　e: MAIL FROM　f: y-sha.com

この問題はSMTPの基本的なフローの理解ができているかを問われている。なので、SMTPフローを見ていこう！

▼SMTPフロー
１．送信前の準備（DNSの引き方）
　メールを送り出す前に、送信側サーバーは「どこにコネクトすればいいか」を調べるためにDNSを引く。（＝MXレコードとA/AAAAレコードの取得）
２．TCP接続とSMTPセッションの開始
　特定したIPアドレスの ポート25番 に向かってTCPのコネクションを張り、ここからSMTPの会話（セッション）を始める
　①送信側が接続すると、受信側サーバーがまずウェルカムメッセージ（220応答）を返す
　②その後、送信側が挨拶のコマンド（EHLO/HELO）を送る
　　HELO：ただ挨拶するだけ
　　EHLO：認証、拡張機能などの交渉・確認の役割も持つ
３．エンベロープ（封筒）のやり取り
　ここから「誰から誰に送るのか」という宛先・差出人の情報を伝える（※ここで前述したSPFのチェックが裏で行われる）。
　①MAIL FROM
　　「このメールの差出人は（エンベロープFROM）はこのアドレスですよ」と伝える。
　　例：MAIL FROM:<tarouyamada@example.com>
　②RCPT TO
　　「このメールの宛先（エンベロープTo）はこの人です」と伝える。（複数の宛先がある場合はこのコマンドを繰り返す）。
　　例：RCPT TO:<tarouyamada@example.com>
４．本文データの送信
　封筒の宛先が決まったら、いよいよ中身（便箋）を送り始める。
　①DATA
　　「これより後ろはすべてメールのデータ（ヘッダーと本文）だよ」と受信側に伝える。受信側がOK（354応答）を返すと、データ送信モードに入る。
　②ヘッダーと本文の送信
　　From: 太郎 <tarouyamada@example.com>
　　To: 花子 <recipient@example.com>
　　Subject: 会議の件
　　（空行）
　　本文のテキスト
５．切断
　　QUIT
　　「もう用事は済んだので切断します」と伝え、お互いにコネクションを閉じます。

以上の流れより、MAIL FROMコマンドで得られるドメインはメール送信元のメールアドレス。つまり、この場合だと、y-sha.comになる。

設問３

（３）受信したメールが正規のメールサーバから送信されたものかどうかが分かるから

DKIMでは受信者が送信者の公開鍵を使って署名を検証する。その検証が成功するということは、送信者が正しい秘密鍵を保持していることを意味する。つまり、送信者の正当性が保証できるということ。

設問4

（1）DNSサーバ名：外部DNSサーバY　登録する情報：メール中継サーバZのIPアドレス

SPFの検証方法が頭に入っていれば、この問題は解けるようになっている(SPFについてはこちら）。
Z社はY社ドメインを使っているので、受信者はY社のDNSにSPFを要求する。しかし、実際の送信元はZ社の中継メールサーバである。そこで、不整合が起きてしまわないように、Y社側のSPFレコードにZ社の中継メールサーバのIPアドレスを登録しておけば整合性が取れる。

Q.include使った方が効率よくね？
A.Yes！！includeを使わないと、Z社の中継メールサーバのIPアドレスが変わるたびにY社のSPFレコードの更新をしなくてはならなくなる。それよりも、Z社側でドメインを管理した方が、Z社中継メールサーバのIPが変わったとしても、Y社には影響を与えずに運用を続けることができる。

（２）j: y-sha.com

Q. d=をz社のドメインにした方が効率がいいのでは？
だって、実際に署名しているのはZ社サーバなんだから、なぜそこでわざわざd=をy-sha.comにするのかがよくわからない。。
A.本文をよく見ると、「外部DNSサーバYを使用してDKIMの検査を行うことができるように~」と記されている。つまり、Y社のDNSサーバを使わせたいので、必然的にY社ドメインを指定することになる。

また、現在のセキュリティにおいては、FromドメインとDKIMドメインが一致していないと正当なメールとして認められないこともある。そのため、Y社のDNSを使わせている。

（３）メール中継サーバZから鍵が漏洩しても、Y社で実施中のDKIMの処理は影響を受けない。

Z社の秘密鍵（セレクター：sel.zsha）が漏洩した場合、攻撃者はZ社が担当するサポートメールなどを偽装できるリスクが生る。だけど、Y社自身が元々使っている本体のメールシステムは別の秘密鍵を使用しているため、その安全性は一切脅かされない。

（４）なりすましメールもメール中継サーバZから社外に転送されるから

これは何を意味しているかというと、Z社のメール中継サーバを使えるなら誰でもy-sha.comを送信元にできて、認証も通ってしまうということを意味する。そのため、Z社内からスパムメールを大量に送ったりなりすましをしたりできてしまうということ。
で、設問では、それがなぜか？と聞かれている。
A.メールが中継サーバを通りさえすれば、誰が書いたメールであってもサーバが勝手に認証を通れるように作動してしまう。つまり、DKIMはあくまでもサーバ単位の正当性を認証するものであるため、そのサーバを使えさえすれば誰でも認証を通過できてしまう。なので、ユーザ単位の認証が必要になる。

Q.じゃあ、どうすればいいの？
A.S/MIMEを使う。DKIMはサーバ単位の署名。S/MIMEは個人単位の署名なので不正なユーザであれば認証を通らせなくできる。

設問５

（１）　送信者の秘密鍵でハッシュ値を暗号化する

電子署名データの作成は、ハッシュ値を秘密鍵で暗号化することで作成できる。これはS/MIMEに限った話ではなく、署名を作るときの流れは大抵この方式で作られる。

（２）　送信者の公開鍵で署名を復号する

署名は送信者の秘密鍵で暗号化されているので、それを復号すればハッシュ値を取り出すことができる。そして、秘密鍵で暗号化されたものを復号できる鍵は、そのペアの公開鍵なので、回答も送信者の公開鍵となる。

（３）　取り出したハッシュ値と生成した値が一致する

送信側と受信側で生成したハッシュ値が一致することは、改ざんがされていないことの証明になる。　

p.3 図３ 社内DNSサーバYが管理するゾーン情報の見方ｰｰｰｰｰｰｰｰｰ

Q.急にドメイン「.lan」とかが出てきたり、同じIPアドレス（192.168.0.1,192.168.0.2）を持つレコードが出てきたりと、意味不明。。。。なので、１行ずつ冷静に見ていこう！
A.以下を見ていこう！
①y-mail3.y-sha.lan. IN A 192.168.1.1
図１サーバセグメント内の社内メールサーバYのホスト名とIPアドレスをあらわしている。
②③mail.y-sha.lan. 60 IN A 192.168.0.1 （と .2）
図１中のDMZにあるメール中継サーバY1とY2の代表エイリアス
２行あることでラウンドロビンが可能になる。
④⑤ y-mail1.y-sha.lan. / y-mail2.y-sha.lan. IN A 192.168.0.1 （と .2）
管理目的で明示的に社内からDMZの中継サーバにアクセスしたいときに使う。②③だとラウンドロビンされてしまうので、意図した方のサーバにアクセスできないから。

Q.どうゆう流れでDNSレコードが参照されているのかよくわからない。。。
A.では、フロー（社内PC→外部ホスト）を参照しながら疑問を解消していこう！
１．社内PCがメールを作成
２．PC内のメールソフトクライアントが社内メールサーバYへ送信
＊運用ルールで、本文中に社内メールサーバYを経由すると記されているので、Yを経由させる

本文中に明示

＊メールサーバYを経由させるには、メールソフトクライアントにメールサーバYのFQDN（y-mail3.y-sha.lan. ）やIPアドレスをリレーサバ（スマートホスト）として設定しておく
→この時に使われるレコードが①。これによってメールサーバYへ到達できる
３．社内メールサーバYから中継メールサーバへ
社内メールサーバYにもスマートホスト（リレーサーバ）として中継メールサーバのFQDN（mail.y-sha.lan.）を設定しておくことで転送処理がスムーズにできる。
４．中継メールサーバから外部ホストへ
中継メールサーバはアプリケーション層内の宛先ドメインを確認し、名前解決によってMXレコード、Aレコードを取得し当該メールサーバへ転送する。

SPF(Sender Policy Framework)とは？——

SPFは送信元のドメインの正当性を確認する仕組みのひとつ。では、そのフローを見ながら理解していこう！

▼SPFフロー
１．接続とMAIL FROMの通知（送信側→受信側）
　送信側サーバーが受信側に接続し、MAIL FROM: <xxx@example.com>（エンベロープFrom）を送信する。
２．IPとドメインの取得（受信側）
　受信側は、いま接続してきている送信元のIPアドレスと、MAIL FROM で指定されたドメイン名を保持する。
３．SPFレコードの問い合わせ（受信側 ➔ DNS）
　受信側は、取得したドメインのDNSサーバーに対して、SPFレコード（TXTレコード）を自分から問い合わせに行く。
４．照合と判定（受信側）
　DNSから返ってきたSPFレコードの中に、「いま接続してきている送信元IPアドレス」が許可されたものとして書かれているかを確認する。

ShellScript
v=spf1 ip4:192.0.2.1 ip4:192.0.2.0/24 include:_spf.google.com ~all

#解説
v=
　SPFのバージョン
　
include:ドメイン名
　メール配信をクラウドサービスなどに委託している場合に、当該サービスのSPFを参照してもらうための仕組み。また、クラウドのIPは動的にころころ変わる。その度にSPFを修正するのは面倒くさいのでincludeにする。

▼許可リストにない時のルール
~all
 ソフトフェイル（怪しいけどブロックはせず迷惑フォルダやフラグを付ける）
-all
 ハードフェイル（受信拒否）
?all
 ニュートラル（何も判断しない、承認成功も失敗もしない。ただの保留＝事実上の無効化）
+all
 パス（誰であろうと全部認証成功！正しいユーザと承認する）

５．結果に応じた処理
　含まれていた場合（合格）: そのまま通信を続け、後続の本文（DATAコマンド）を受け入れる。
　含まれていなかった場合（不合格）: 本文データを受け取る前に、その場でメールの受信を拒否する。

以上！（設問４(1)に戻る）

DKIM(DomainKeys Identified Mail)とは？—–

DKIMも送信元ドメイン認証の方法の一つ。では、フローを見ながら理解しよう！

▼DKIMのフロー
＊前提：DKIMに使う鍵は第三者認証ではなく各サイトの管理者が生成する
１．DKIM署名ヘッダーの読み取り
　受信したメールのヘッダーから DKIM-Signature: を見つけ出し、そこに書かれている以下の情報を抽出する。
d= （ドメイン名）：例 example.com
s= （セレクター名）：例 selector1
a= （アルゴリズム名）：例 rsa-sha256　暗号化にはRSAを、ハッシュにはsha256を利用している意
b= （署名データ）：送信側が付けた電子署名そのもの
２．公開鍵の取得（DNS問い合わせ）
　抽出したドメインとセレクターを組み合わせて、DNSに公開鍵を要求する。
　問い合わせ先の形式: selector1._domainkey.example.com のTXTレコード

ShellScript
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0v... (長い公開鍵文字列) ..."


#詳細解説
selector1._domainkey.example.com.
　セレクタ：ただTXTレコードを取得するだけだとたくさんあって、どのTXTか判断できない。そこでセレクタという識別子を使うことで数あるTXTレコードから適切なレコードを取得できる
　
v=
 バージョン
 
k=
 暗号アルゴリズム
 
p=
　公開鍵の実データ

３．署名の検証（復号とハッシュ比較）
取得した公開鍵を使って、メールに添付されていた電子署名（b=）を復号し、送信側が作った「元のハッシュ値」を取り出す。
同時に、受信側自身でも手元に届いたメールの本文等を同じアルゴリズムでハッシュ化し、「受信側で計算したハッシュ値」を作る。
４．署名の検証（復号とハッシュ比較）
　取得した公開鍵を使って、メールに添付されていた電子署名（b=）を復号し、送信側が作った「元のハッシュ値」を取り出す。
　同時に、受信側自身でも手元に届いたメールの本文等を同じアルゴリズムでハッシュ化し、「受信側で計算したハッシュ値」を作る。
５．照合と判定
　「公開鍵で復号したハッシュ値」と「受信側で計算したハッシュ値」を比較する。
　一致した場合: 途中で改ざんされておらず、かつ、そのドメインの秘密鍵を持っている正当な送信者から送られたものであると証明されるため 【合格（Pass）】 となる。
　一致しなかった場合: 途中でデータが書き換えられている（改ざん）、あるいは偽の署名であるため 【不合格（Fail）】 となる。

以上がフロー。ただしこのフローからもわかる通り、Header Fromの確認はしないので、そこの偽造を検知するにはまた別の機能が必要となる。。。

p.19 Y社の運用ポリシーについて

Y社ではメールを運用においてポリシーを制定している。この一つずつの意図を理解していこう！

(あ)　社内メールサーバYには、Y社に勤務する従業員以外のメールボックスは設定しないこと

Q.なんでY社以外のメールボックスは設置しないの？意図は？
A.無関係のアカウントが存在していると、そのアカウントを皮切りに社内への不正アクセスなどにつながってしまうから。社内ドメインのアカウントが不正に利用されると、同じドメインであるためチェックが緩くなったりして、通常の外部アカウントよりも不正にできることが増えてしまう。

(い)　社内PCによるメール送受信は、社内メールサーバYを介して行うこと

Q.なんで社内メールサーバYを介すの？直接、中継メールサーバに送っちゃダメなの？
A.社内からでるすべてのメールを一元管理・統制するため。これをすることによって、社内メールサーバYへのセキュリティ対策が社内メール全体に波及させることができるから。もし、一元化しないと、各PCが勝手に外部と直接メールをやり取りすると、会社側がウイルスチェックやログの監査、誤送信防止などのセキュリティ対策を一切コントロール（一元管理）できなくなる。

(う)　メール中継サーバY1及びY2にはメールボックスは設定せず、社内メールサーバYから社外宛て、及び社外から社内メールサーバY宛ての、メールだけを中継すること

Q.なんで中継メールサーバにメールボックスを置かないの？
A.中継メールサーバはDMZ、つまり外部からアクセス可能な領域に配置されている。この場所でメールボックスを置くと、外部からメールボックスの中身を覗かれてしまい情報漏洩などにつながってしまうから。そうならないように、DMZにはメールボックスは配置しない。

Q.送信元と宛先を限定するのはなぜ？
A.踏み台サーバとして利用されることを防ぐため。中継サーバーが誰でもかれでも自由にメールを中継できる状態（オープンリレー）になっていると、世界中のスパム業者に悪用（踏み台に）されてしまう。これをしてしまうと、メールプロバイダのブラックリストに登録されてしまいY社自身のメール送受信が停止されてしまう。

(え)　Y社のドメインを利用するメールには、なりすまし防止などの情報セキュリティ対策を講じること

A.これは疑問の入り込む余地すらないことだが、SPFやDKIMなどのセキュリティ対策をすることによって、正規の送信元であるお墨付きを作る。

p.20 Z社に委託するメールによるサポート方法

Q.これはどういうこと？

A.これは、Z社のサポートチームYにY社のsupport@y-sha.comを使用させるということ。送信元をsupport@y-sha.comとしてメールを送れるようにしている。

Q1.抽出して転送ってどうやって？

A1.Y社のメールサーバにフィルター付きのソフトを稼働させることで、Z社に依頼している製品にヒットしたメールを転送するという仕組みを構築する。

Q2.転送時の送信元/宛先はどうなる？

A2.送信元はY社のメール中継サーバになり、宛先はZ社のグループアドレスになる。

ShellScript
#Z社に届くメール
--------------------------------------------------
【転送メールのヘッダー情報】
From: Y社メールサーバー <mailer@y-sha.com>  ← ここは転送元（Y社）になる
To: Z社グループアドレス <support-team-y@z-sha.co.jp>
Subject: 【転送】製品についての問い合わせ

【転送メールの本文（ここがポイント）】
---------- Forwarded message ----------
From: 困っている顧客 <customer@example.com>  ← ★ここに元々の顧客のアドレスが残っている
To: support@y-sha.com
Subject: 製品が動きません

はじめまして、〇〇の製品について質問なのですが...（顧客の問い合わせ内容）
--------------------------------------------------

で、Z社からクライアントに返信する時の送信元にはy-shaドメインを使う。

Q3.Z社からの返信はどうなるの？なんか、送信元をy社ドメインにするときと、z社ドメインにするときの切り替えはどうやってるの？面倒くさくない？

A3.通常のOutlookなどのメールクライアントは使わずにServiceNowのようなITサービスマネジメントプラットフォームを導入することが多い。宛先ごとにメール送信元を手動で変更したりするのはとても手間がかかるので、メールクライアントで制御するよりも専用のシステムを利用する。

p.21 S/MIMEとは？——

DKIMはサーバ単位の認証。一方、S/MIME（Secure/Multipurpose Internet Mail Extensions）はユーザ単位の認証をサポートする。では、どのように実施するのか？フローとともに見ていこう！

▼S/MIMEのフロー
１．証明書の発行
サポート担当者（例：佐藤さん）は、信頼できる認証局（CA）から「佐藤さん本人＝ support@y-sha.com の持ち主」であることを証明する電子証明書と秘密鍵を発行してもらう。（秘密鍵・公開鍵
Q.どこのCAから発行するの？
A.証明書でやりたいことは、「Y社の一員ですよ！」とやりたい。なので、発行する主体のCAはY社のCAである。
２．メール作成・送信
佐藤さんがパソコンのメールソフトでメールを書き、送信ボタンを押す。
この時、メールソフトが佐藤さんの「秘密鍵」を使って、メール本文にデジタル署名（電子的なハンコ）をペタッと貼り付ける。
３．受信側で検証
顧客のメールソフトがメールを受信する。
受信側のソフトは、メールについている署名を見て、「これ本当に佐藤さん（support@y-sha.com）が書いたものか？」を、認証局の公開鍵を使ってチェックする。

MUA,MAT,MDAとは？—-

メールのフローを勉強していると必ずと言っていいほど出てくる用語がある。それを見ていこう！

名称正式名称わかりやすい役割具体例
MUAMail User Agentメールを書く・読むソフト（ユーザーの道具）Outlook、Thunderbird、Gmailアプリ
MTAMail Transfer Agentメールを運ぶ・中継するサーバー（郵便局・トラック）Postfix、Sendmail、今回の問題の「メール中継サーバZ」
MDAMail Delivery Agentメールを届けて保存するサーバー（各個人の郵便受け）Dovecot、Cyrus（受信箱に格納する役割）

不備により設問５は成立しないとは？—

Q.問題文を読んだいる限り目立った矛盾点はなさそう。。。。ではどこが不備なのか？
A.本文中に「秘密鍵を共有する」旨の記述がある。

本来、秘密鍵とは共有するものではない。また、S/MIMEは個人の証明をするものなのに、その情報を共有するとなるとS/MIMEの根幹部分に矛盾を生じさせるようなものである。
。。といった理由で不備とされている可能性があるかもしれない。。


　




タイトルとURLをコピーしました