【新卒未経験向け＆第二新卒 現場上級向け】朝の口頭試問_Day5_Day4振り返り　面白きこともなき世をおもしろく

Day 5 Morning 朝の口頭試問 Day 4 振り返り ― メール配送（SMTP / Postfix / Dovecot） Pattern A Pattern B 新卒未経験向け 第二新卒 現場上級向け LPIC レベル2 基礎確認 / 図解どおり PJ前提条件付き応用 / 設計・障害対応判断 | 講師: 石黒友季子 面白きこともなき世をおもしろく

Intro | 進め方 朝の口頭試問 ― 所要時間: 約30分 本日の口頭試問の進め方 1 Pattern A (約15分) 新卒未経験向け - 5問。Day4の図解そのまま、用語と数字の即答練習。 2 Pattern B (約15分) 現場上級向け - 5問。PJ前提条件を読み、設計判断 / 切り分け手順を口頭説明。 3 ルール 1問あたり考える時間 3分 → 口頭で回答 → 解説。分からない場合は素直に「分かりません」でOK。 4 ゴール Day5 (DNS構築 + メール配送完成) へ向け、Day4知識を口頭で再現できる状態を作る。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 2 / 24

Pattern A 新卒未経験向け ― LPIC レベル2 基礎確認 Day4の図解そのまま。3人の登場人物・ポート番号・main.cf 6項目・切り分け5ステップなど、用語と数字を「 即答」できる状態にする。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 3 / 24

Section A | 新卒未経験 / LPIC2 基礎 Q1 問 Q1 / 5 ― MUA・MTA・MDA メール配送に登場する「3人」を答えなさい メールが送信者から受信者のメールボックスへ届くまでに登場する 3つの役割（MUA / MTA / MDA）について、 (1) それぞれの正式名称（英語） (2) ラーメン出前で例えるとどの役か (3) 代表的なソフトウェアを1つずつ を口頭で答えてください。 考える時間: 30秒 | ヒント: うさうさラーメン店の図解どおり。お客 / 配達バイク / 配膳係。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 4 / 24

Section A | 新卒未経験 / LPIC2 基礎 A A1 / 5 ― MUA・MTA・MDA Q1 メール配送の3人 MUA = お客 / MTA = 配達バイク / MDA = 配膳係 MUA (Mail User Agent) ― お客さん ・メールを書く・読む人のアプリ。例: Thunderbird / Outlook / Gmail / mail コマンド MTA (Mail Transfer Agent) ― 配達バイク ・メールを運ぶ配送業者。例: Postfix / Sendmail / qmail / Microsoft Exchange MDA (Mail Delivery Agent) ― 配膳係 ・受信したメールをメールボックスへ配達。例: Postfix(MTA兼任) / Procmail / Dovecot LDA ★ 試験/現場ポイント: 「PostfixはMTAだがMDAも兼任できる」が頻出。Dovecotは受信プロトコル(IMAP/POP3)担当。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 5 / 24

Section A | 新卒未経験 / LPIC2 基礎 Q2 問 Q2 / 5 ― SMTPポート3兄弟 SMTPのポート番号「3兄弟」を答えなさい メール送信(SMTP)で使われる3つのポート番号について、 (1) ポート番号 (2) 名称 (SMTP / Submission / SMTPS) (3) 認証の有無 (4) 用途 (MTA間 or MUA→MTA) を3つすべて口頭で答えてください。 考える時間: 30秒 | ヒント: 25 / 587 / 465 の順で答えればOK。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 6 / 24

Section A | 新卒未経験 / LPIC2 基礎 A A2 / 5 ― SMTPポート3兄弟 Q2 SMTPポート3兄弟 25 (SMTP) / 587 (Submission) / 465 (SMTPS) 25 / SMTP ・MTA間通信。認証なし。サーバー同士のメール中継で使用。 587 / Submission ・MUA→MTA送信。認証必須(SASL)。現在のクライアント送信の標準。 465 / SMTPS ・SSL/TLS暗号化SMTP。一度廃止 → 現在は復活して併用。 ★ 試験/現場ポイント: 「25は認証なしだからオープンリレーになりやすい」「クライアント送信は587 + 認証」が試験頻出。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 7 / 24

Section A | 新卒未経験 / LPIC2 基礎 Q3 問 Q3 / 5 ― オープンリレー オープンリレー問題について答えなさい 「オープンリレー」とは何か、 (1) 誰でもこのMTAを使って、どこから・どこへ・どんな問題があるか (2) 正しい状態 (誰なら送信OK か) (3) Postfix main.cf で対策に必須のパラメータ名 を口頭で説明してください。 考える時間: 30秒 | ヒント: 対策パラメータは「smtpd_◯◯_restrictions」。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 8 / 24

Section A | 新卒未経験 / LPIC2 基礎 A A3 / 5 ― オープンリレー Q3 オープンリレー問題 誰でも中継OK = 迷惑メール踏み台。SASL認証 + 自ドメイン宛のみ受信が正解 悪い状態 ・誰でもこのMTAを使って世界中にメール送れる = 迷惑メール踏み台。 正しい状態 ・認証された人 (SASL) だけ送信OK + 自ドメイン宛だけ受信。 対策コマンド smtpd_recipient_restrictions = reject_unauth_destination を必ず指定。 ★ 試験/現場ポイント: 「reject_unauth_destination を入れないと外部宛中継を許す」が定番引っかけ問題。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 9 / 24

Section A | 新卒未経験 / LPIC2 基礎 Q4 Q4 / 5 ― Postfix main.cf 6項目 Postfix main.cf で編集する「6項目」を答えなさい 問 Postfix の main.cf でメール送受信を成立させるために 編集する 6 つのパラメータ名と、その役割を口頭で答えてください。 ヒント: myhost… / mydom… / inet_… / mydest… / smtpd_sasl… / smtpd_recipient… 考える時間: 30秒 | ヒント: 「自分の名前」「自分のドメイン」「待ち受けIF」「受信対象ドメイン」「SASL認証」「中継制限」 の6個。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 10 / 24

Section A | 新卒未経験 / LPIC2 基礎 A A4 / 5 ― Postfix main.cf 6項目 Q4 main.cf 6項目 myhostname / mydomain / inet_interfaces / mydestination / smtpd_sasl_auth_enable / smtpd_recipient_restrictions myhostname = mail.example1.jp mydomain = example1.jp ホスト名 (FQDN) 自ドメイン inet_interfaces = localhost, 192.168.56.101 ※localhost 必須 待ち受けIF mydestination = $mydomain 受信対象ドメイン smtpd_sasl_auth_enable = yes smtpd_recipient_restrictions = permit_mynetworks, 末尾に追記 (SASL認証ON) permit_sasl_authenticated, reject_unauth_destination 踏み台防止 ★ 試験/現場ポイント: inet_interfaces から localhost を外すと配送系が壊れる。「localhost 必須」を即答できること。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 11 / 24

Section A | 新卒未経験 / LPIC2 基礎 Q5 Q5 / 5 ― メールが詰まったときの切り分け メールが届かない時の切り分け5ステップを答えなさい 問 Postfix でメールが詰まったとき、上から順番に実行する 「5ステップ」をコマンド付きで口頭で答えてください。 (1) 構文 → (2) サービス → (3) ポート → (4) FW → (5) ログ 考える時間: 30秒 | ヒント: postfix check / systemctl / ss -tulnp / firewall-cmd / tail -f /var/log/maillog うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 12 / 24

Section A | 新卒未経験 / LPIC2 基礎 A A5 / 5 ― 切り分け5ステップ Q5 切り分け5ステップ 構文 → サービス → ポート → FW → ログ の順で必ず上から (1) sudo postfix check (2) sudo systemctl status postfix (3) sudo ss -tulnp | grep :25 構文OK? active? LISTEN? (4) sudo firewall-cmd --list-services smtp 開放? (5) sudo tail -f /var/log/maillog ログ確認 ログのキーワードで原因特定 ・status=sent → 送信成功 / User unknown → useradd 忘れ ・Relay access denied → main.cf 制限再確認 / Connection refused → postfix未起動 or FW未開放 ★ 試験/現場ポイント: 「いきなりログを見ない」が現場の鉄則。上の4つで切り分けてからログで詳細を裏取り。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 13 / 24

Pattern B 第二新卒 現場上級向け ― PJ応用 各問にPJ前提条件 (顧客 / 環境 / 要件 / 制約) を提示。設計判断 / 監査対応 / 障害切り分けを「自分の言葉で」口 頭説明できる状態を目指す。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 14 / 24

Section B | 第二新卒 現場上級 / PJ応用 B1 Q1 / 5 ― 監査対応 監査でオープンリレー検知。あなたの初動と恒久対策を述べよ 【 PJ 前提条件 】 【問】 ■ 顧客 / 案件 (1) 今夜中に行う暫定対応 金融系SI 二次請け案件。 中堅生保のメール基盤(社内→社外通知用)。 FW / Postfix どちらを先に触るか、理由付きで。 ■ 環境 RHEL 8 / Postfix 3.5 DMZのSMTP中継サーバー × 2台 (HA) 前段にFW、外部宛 25/tcp 開放 ■ 状況 外部監査で 「smtp-relay-test.org からの リレーテストに応答した」 と指摘。 重大インシデント扱い、48h以内回答必須。 (2) 恒久対応の main.cf 設定 具体的パラメータを最低3つ、 permit_mynetworks の位置順序も含めて。 (3) 監査向けエビデンス 「対策後はリレーしない」を どうログ・コマンドで証明するか。 ■ 制約 メール業務は止められない。 リリース手順書 + 切り戻し手順 が必須。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 15 / 24

Section B | 第二新卒 現場上級 / PJ応用 A A1 / 5 ― 監査対応 B1 監査オープンリレー検知の初動・恒久・エビデンス FW即時遮断ではなく Postfix 側で reject_unauth_destination 投入 → 切り戻し可能で業務継続 (1) 暫定対応 ― Postfix 側を先に ・FWで 25 を遮断するとメール業務全停止 = NG。 ・main.cf に smtpd_recipient_restrictions を追記 → postfix reload で無停止対応。 (2) 恒久対応 main.cf (順序が重要) smtpd_recipient_restrictions = permit_mynetworks, ← 自社NWは最初に許可 permit_sasl_authenticated, ← 認証済みも許可 reject_unauth_destination ← それ以外の外部宛は全拒否 ・順序を逆にすると社内通信も reject にヒットして止まる。 (3) エビデンス ・swaks で外部宛リレーテスト → maillog の Relay access denied をCSV化して提出。 ★ 現場で問われる本質: 監査対応では「業務影響なく止める方法」と「証跡」の2軸。reload で済む対策を先に出すのが上級。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 16 / 24

Section B | 第二新卒 現場上級 / PJ応用 B2 Q2 / 5 ― 設計判断 クライアント送信ポートに 587 と 465 のどちらを採用すべきか 【 PJ 前提条件 】 【問】 ■ 顧客 / 案件 (1) どちらを採用するか結論 (2) その理由を STARTTLS と 暗黙的TLS EC事業者の新規メール基盤刷新PJ。 受発注通知 / マーケメール 月間500万通。 ■ 要件 ・全クライアント サーバー間で TLS 必須 ・社外コンタクトセンター(委託先)からも送信 ・モバイルアプリ(Android/iOS)からも送信 ・送信失敗率を 0.1% 以下に抑えたい の違いから説明 (3) 古い委託先システムが 587 に 対応していなかったとき、 あなたはどう設計するか (4) main.cf / master.cf どちらで 設定するか、その理由 ■ 既存環境 現行は 25/tcp 平文。これを 587 or 465 に 切替提案する必要あり。 ■ 制約 ベンダ非依存。古い委託先システムも一部存在。 メールクライアントの選択肢は自由。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 17 / 24

Section B | 第二新卒 現場上級 / PJ応用 A A2 / 5 ― 設計判断 B2 587 vs 465 採用判断 原則587(STARTTLS) を採用。互換性確保のため 465(SMTPS) も併用 = 両方開ける構成が現実解 (1)(2) 結論と理由 ・587 は STARTTLS。接続は平文 → TLSへアップグレード。RFC 6409 標準で SASL 認証前提。 ・465 は接続時から暗黙的TLS。古いクライアント・SDK の互換用途で需要が再評価され復活。 ・新規設計なら 587 主体が正。ただし古い委託先が STARTTLS非対応なら 465 を併用。 (3) 古いシステム対応 ・master.cf で submission(587) と smtps(465) の両方を有効化。submission 配下に -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=encrypt を上書き指定。 (4) main.cf / master.cf の使い分け ・全体共通 = main.cf。ポート別の上書き = master.cf。「-o」で port 単位に override するのが Postfix 流儀。 ★ 現場で問われる本質: 「-o オプションは master.cf でしか効かない」「465はTLS必須・587はSTARTTLS」を即答できれば現場上級。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 18 / 24

Section B | 第二新卒 現場上級 / PJ応用 B3 Q3 / 5 ― 障害対応 早朝7時、顧客から「請求書メールが届かない」連絡。あなたの動きは 【 PJ 前提条件 】 【問】 ■ 顧客 / 案件 (1) 7:00〜9:00 の2時間で BtoBサービス事業者。月初に全顧客 (約3万社) へ 請求書メール一斉配信。 必ず実行する切り分けコマンドを 上から順に5つ口頭で挙げる ■ 状況 今朝 6:00 のバッチで配信実行。 7:00 に複数顧客から「届かない」連絡。 運用Slackにアラート発報、一次受けはあなた。 ■ 環境 RHEL 8 / Postfix 3.5 + Dovecot 送信ログ = /var/log/maillog (2) maillog で見つけた status=bounced 「User unknown in local recipient table」 この原因と対処は何か (3) もし status=sent ばかりが並んでいたら、 原因はどこにあると判断するか ■ 制約 原因切り分け中も顧客窓口は止まらない。 9:00 の経営朝会で第一報 必須。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 19 / 24

Section B | 第二新卒 現場上級 / PJ応用 A A3 / 5 ― 障害対応 B3 早朝メール未達障害の切り分け 5ステップ切り分け → status= の値で「自社内 / 自社外」のどちらに原因があるかを早朝で確定させる (1) 5ステップ (Day4の手順そのまま現場応用) (1) sudo postfix check (2) sudo systemctl status postfix (3) sudo ss -tulnp | grep :25 (4) sudo firewall-cmd --list-services (5) sudo tail -f /var/log/maillog | grep <Message-ID> (2) User unknown in local recipient table ・MTAは正常。MDA配送時に宛先ユーザーがOSに存在しない or virtual_mailbox 未登録。 ・対処: useradd / virtual_alias_maps / mydestination の再確認。送信元へは bounce で「アドレス不在」を返すのが正。 (3) status=sent ばかりが並ぶ場合 ・自社MTAは送信完了 → 原因は受信側(迷惑判定 / MX障害)。次は DNS の MX/SPF/DKIM/DMARC 確認に切替。 ★ 現場で問われる本質: 「status= で自社内/外を切り分ける」 がメール障害の現場鉄則。9時報告で「自社問題ではない」と言い切れるかが価 値。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 20 / 24

Section B | 第二新卒 現場上級 / PJ応用 B4 Q4 / 5 ― 構築トラブル テスト送信が突然 Connection refused。原因と対策は 【 PJ 前提条件 】 【問】 ■ 顧客 / 案件 (1) 即答: なぜ Connection refused か 社内リプレースPJ。新規 Postfix サーバー (192.168.56.101 / RHEL 8) を結合テスト直前。 inet_interfaces の意味から説明 ■ 直前の作業 セキュリティ部から「外部公開IPだけに Listenするように」と指示があり、main.cf を修正: ■ 修正後 main.cf inet_interfaces = 192.168.56.101 (localhost を外した) mydestination = $mydomain (2) main.cf をどう直すか セキュリティ部の意図も尊重する案で (3) localhost を外す危険性を 「postfix が内部で何をするか」から 説明せよ (sendmail コマンド経由の cron や httpd からのメール送信は どう動くか) ■ 症状 ・systemctl status postfix → active(running) ・swaks --to [email protected] → Connection refused 多発 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 21 / 24

Section B | 第二新卒 現場上級 / PJ応用 A A4 / 5 ― 構築トラブル B4 inet_interfaces から localhost を外した事故 localhost を外すと postfix 内部のローカル投函(127.0.0.1)が拒否される。両方Listenが正解 (1) Connection refused の理由 ・inet_interfaces は Postfix が Listen する IP の集合。localhost を外すと 127.0.0.1:25 で待ち受けない。 ・swaks や sendmail コマンドはまず 127.0.0.1 に投げるため、即 Connection refused になる。 (2) 修正 inet_interfaces = localhost, 192.168.56.101 ・「外部公開は1つのIPだけ」要件は満たしつつ、ローカル投函経路を維持できる。 (3) localhost を外す危険性 ・cron / logwatch / httpd / アプリケーション の「sendmail コマンド」は全部 127.0.0.1 経由でMTAに投げる。localhost を外すとこ れらが全部届かなくなる = 監視メールも飛ばない。 ・本来「外部に出さない」要件は firewall-cmd 側で制御すべき。main.cf で実現するのは設計違反。 ★ 現場で問われる本質: 「セキュリティ要件は適切なレイヤで実現する」(FWの仕事をPostfixでやらない) — これが現場での設計力。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 22 / 24

Section B | 第二新卒 現場上級 / PJ応用 B5 Q5 / 5 ― 受信プロトコル / 移行設計 オンプレ→クラウド メール移行。Dovecot 設計と FW 方針を述べよ 【 PJ 前提条件 】 【問】 ■ 顧客 / 案件 (1) Dovecot で使う受信プロトコル 中堅メーカーのメール基盤を オンプレ → AWS (EC2 / Postfix+Dovecot) へ。 ユーザー約2,000 / メールボックス計1.5TB。 POP3 と IMAP のどちらを どんな理由で採用するか ■ 要件 ・受信は Thunderbird / Outlook / iPhone ・社外から受信できること (在宅勤務) ・全経路 TLS 必須 ・移行後も既存 PST/mbox を参照可能 (2) 平文と SSL/TLS版の ポート番号を 4 つ口頭で言う (POP3 / POP3S / IMAP / IMAPS) (3) FW で開放するポートと 許可方針 (在宅勤務想定) ■ 環境 ・送信: 587 + SASL (構築済) ・受信: Dovecot (今回設計対象) ・前段にALB / FW ・社外公開IP は EIP 1個のみ うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 (4) Thunderbirdから接続できるまで に Dovecot 側で編集するファイル数 とその役割概要 23 / 24

Section B | 第二新卒 現場上級 / PJ応用 A A5 / 5 ― 受信プロトコル / 移行設計 B5 Dovecot 設計 と FW 方針 原則 IMAPS(993) のみ採用。在宅前提なら SSL/TLS 版に限定し、平文 110/143 は閉じる (1) POP3 vs IMAP ・複数端末(PC/iPhone)で同じメールを見るなら IMAP 一択。POP3は取得後ローカル管理で端末間同期不可。 (2) 受信ポート4種 POP3 = 110 IMAP = 143 POP3S = 995 IMAPS = 993 (3) FW 開放方針 ・許可: 993/tcp (IMAPS) + 送信用 587/tcp のみ。 ・閉鎖: 110 / 143 (平文)。社外公開で平文受信は監査で確実に指摘される。 (4) Dovecot 4ファイル設定 ・dovecot.conf / 10-mail.conf / 10-auth.conf / 10-ssl.conf + FW で imaps 開放。 ★ 現場で問われる本質: 受信は IMAPS のみ + 送信は 587 = 「SSL/TLS版だけ開ける」が在宅勤務時代の標準解。試験では4ポートの数字、現 場ではFW方針が問われる。 うさうさ先生 | PSC様 Linux応用 Day5 朝の口頭試問 24 / 24