応用情報技術者 2014年 秋期 午後 問05
メールサーバの移行に関する次の記述を読んで、設問1~5に答えよ。
P社は、オフィス事務用品を通信販売する会社である。P社の顧客は首都圏を中心に約300社あり、顧客からの注文を電子メール(以下、メールという)で受け付けている。また、定期的にメールマガジンを用いた商品の宣伝を行っている。
P社では、現在使用しているメールサーバの老朽化に伴い、メールサーバをクラウドサービスへ移行することになった。クラウドサービスへの移行は、P社情報システム課のQ君が担当することになった。
〔現在のネットワーク構成の調査〕
Q君は、メールサーバのクラウドサービスへの移行に向けて、現在のネットワーク構成の調査を行った(図1)。

P社は“p-sya.example.jp”のドメイン名を使用しており、名前解決はP社のDNSサーバで行っている。メールの送受信には、メールサーバを利用しており、社員のメールが蓄積されるメールボックスもメールサーバ内にある。
社員は、PCにインストールされたメールソフトを利用してメールの送受信を行っている。PCからメールサーバへのメールの送信プロトコルはaを利用しており、メールの受信は、メールをPCにダウンロードするbと、サーバ上で管理するcの両方のプロトコルを利用可能としている。また、PCからインターネット上のWebサイトへアクセスする場合は、全てプロキシサーバを経由する規程としている。
メールマガジン配信サーバは、担当者が Webブラウザでアクセスし、配信するメールマガジンの本文を入力すると、配信を希望する全顧客へメールを送信する機能をもつ。メールマガジン配信サーバには、中継用メールサーバとして “mail.p-sya.example.jp” が設定されており、メールは a を用いて、メールサーバへ送信され、メールサーバのメール転送機能を用いて顧客へ送信される。
〔メールサーバの移行方針〕
情報システム課は、次に示すメールサーバの移行方針を決定した。
・顧客へ再周知しなくても済むように、現在のメールアドレスを継続利用する。
・PC のメールソフトの利用は禁止し、Webブラウザを用いたメールの送受信に切り換える。Webブラウザとクラウドサービスの間の通信には、HTTPS を利用する。
・移行作業中に受信したメールを含め、メールサーバ内の全てのメールを移行する。
・メールマガジンは、メールマガジン配信サーバからクラウドサービスの機能を用いて顧客へ配信する。
・クラウドサービスの利用に際し、情報漏えい対策などのセキュリティ対策を行う。
〔利用予定のクラウドサービス〕
Q君は、〔メールサーバの移行方針〕に合致するクラウドサービスの調査を行い、次の機能をもつクラウドサービス(図2)を利用することにした。
・独自のドメイン名を利用可能であり、クラウドサービスを用いて移行前と同様に p-sya.example.jp ドメインでのメールの送受信が可能である。
・Webブラウザを用いて、クラウドサービスのメール送受信ページにアクセスし、メールの作成や閲覧を行うことが可能である。
・a を用いたメール転送機能が利用可能である。この機能を利用する際は、利用者IDとパスワードを用いた認証が必要である。
・メール送受信ページにアクセス可能な接続元IPアドレスや、他社へのメール転送を許可する接続元IPアドレスを制限できる。
〔メールサーバの移行手順案〕
Q君は、メールサーバのクラウドサービス移行に向けて、移行手順案をまとめた。
なお、メールサーバの移行日程を事前に全社員に連絡し、手順3~5は、休業日のメール利用が少ない時間帯に行うことにした。 手順1.クラウドサービスのセキュリティ設定ページから、メール送受信ページにアクセス可能な接続元IPアドレスをd、メール転送を許可する接続元IPアドレスをeに限定するように設定する。
手順2.クラウドサービスにP社員のメールアドレスを登録し、p-sya.example.jpドメインのメールを送受信可能にする。
手順3.DNSサーバに登録してあるmail.p-sya.example.jpのIPアドレスを、クラウドサービスの管理会社から通知されたIPアドレスに変更する。
手順4.メールサーバのメールボックスに蓄積されている全メールをクラウドサービスのメールボックスに入れる。
手順5.①メールマガジン配信サーバに必要な変更を実施する。
手順6.初期パスワードを社員へ連絡し、メール送受信ページにログイン可能とする。
〔R課長のレビュー指摘〕
Q君は、〔メールサーバの移行手順案〕をR課長にレビューしてもらったところ、次の指摘を受けた。
指摘:移行後もしばらくは現在のメールサーバがメールを受信する可能性があるので、メールサーバは2週間程度残しておく必要がある。また、メールサーバが受信したメールをmail.p-sya.example.jpへ転送する設定を行う必要がある。
その後、Q君はR課長からの指摘を反映させ、メールサーバのクラウドサービスへの移行を完了させた。また、②Webブラウザを用いてメールの送受信を行う方式に変更したことによって、PCがウイルスに感染した場合に、PCから社外へ大量のメールを送信する通信をファイアウォールで遮断することが可能となった。
設問1:
本文中のa〜cに入れる適切なプロトコル名を解答群の中から選び、記号で答えよ。
解答群
ア:FTP
イ:IMAP4
ウ:NTP
エ:POP3
オ:SMTP
カ:SSL
模範解答
a:オ
b:エ
c:イ
解説
解答の論理構成
- 【問題文】には「PCからメールサーバへのメールの送信プロトコルはaを利用」とあります。さらに「メールマガジン配信サーバには…メールは a を用いて、メールサーバへ送信される」とも記載されています。送信用プロトコルとして広く使われるのは「SMTP」です。
- 受信用については【問題文】で「メールの受信は、メールをPCにダウンロードするbと、サーバ上で管理するcの両方のプロトコルを利用可能」と示されています。
- “PCにダウンロードする”方式はローカル保存が前提であり、典型的に「POP3」が用いられます。
- “サーバ上で管理する”方式はメールをサーバ側に残したまま扱うため「IMAP4」が採用されます。
- 以上より選択肢を対応させると
- a=「SMTP」
- b=「POP3」
- c=「IMAP4」
となるため、解答群での記号は a:オ、b:エ、c:イ です。
誤りやすいポイント
- 「POP3」と「IMAP4」を逆に選ぶミス。キーワードは【問題文】の「ダウンロード」と「サーバ上で管理」。
- 「SSL」は暗号化の仕組みであってメール送受信のアプリケーション層プロトコルではない点を見落とす。
- Webブラウザ利用=HTTP/HTTPS と連想し、そのまま a を「FTP」などと誤選択するケース。
FAQ
Q: SMTP も暗号化できますか?
A: はい。TLS/SSL を組み合わせた SMTPS や STARTTLS 拡張で暗号化通信が可能ですが、本設問は“プロトコル名”を問うため平文の呼称「SMTP」で解答します。
A: はい。TLS/SSL を組み合わせた SMTPS や STARTTLS 拡張で暗号化通信が可能ですが、本設問は“プロトコル名”を問うため平文の呼称「SMTP」で解答します。
Q: POP3 と IMAP4 はどちらを使うべきですか?
A: ローカル PC で完結させたい場合は POP3、複数端末から同じメールボックスを扱いたい場合やフォルダ管理が必要な場合は IMAP4 が適しています。
A: ローカル PC で完結させたい場合は POP3、複数端末から同じメールボックスを扱いたい場合やフォルダ管理が必要な場合は IMAP4 が適しています。
Q: メールマガジン配信サーバが SMTP を使う理由は?
A: 大量配信時にメールを一括で中継サーバへ渡すには SMTP が標準であり、他の方式では配送指示ができないためです。
A: 大量配信時にメールを一括で中継サーバへ渡すには SMTP が標準であり、他の方式では配送指示ができないためです。
関連キーワード: SMTP, POP3, IMAP4, メール転送、認証
設問2:
本文中のd、eに入れる適切なIPアドレスを、図1中の字句を用いて答えよ。
模範解答
d:x.y.z.102
e:x.y.z.103
解説
解答の論理構成
-
接続元IPアドレスを制限する対象を整理
- 手順1では「メール送受信ページにアクセス可能な接続元IPアドレス」と「メール転送を許可する接続元IPアドレス」を個別に設定します。
- Webページ経由の送受信は社員の PC から行われ、「PCからインターネット上のWebサイトへアクセスする場合は、全てプロキシサーバを経由する規程としている。」と明記されています。
- メール転送は「メールマガジン配信サーバ」が「a を用いて」クラウド側に送信する仕組みで、HTTP/HTTPS ではなく SMTP 経由です。
-
Webアクセス側 (d) の送信元を特定
- 図1でプロキシサーバに割り振られているグローバル IP は「x.y.z.102」。
- 社員がブラウザでクラウドの「https://www.cloud.example.jp/p-sya/」へ接続すると、外部から見える送信元はこの IP です。
⇒ d = x.y.z.102
-
メール転送側 (e) の送信元を特定
- 「メールマガジン配信サーバ」は LAN 内(192.168.0.253)にあり、直接 SMTP で mail.p-sya.example.jp(=クラウド)へ接続します。
- LAN からインターネットへの出口は、図1でグローバル IP 「x.y.z.103」を持つファイアウォールです。ここが NAT を行うため、外部に見える送信元は「x.y.z.103」となります。
⇒ e = x.y.z.103
-
以上より
- 「メール送受信ページにアクセス可能な接続元IPアドレス」=社員ブラウザ経由のプロキシ IP「x.y.z.102」
- 「メール転送を許可する接続元IPアドレス」=メールマガジン配信サーバを代表する NAT 後 IP「x.y.z.103」
誤りやすいポイント
- プロキシ経由と NAT 経由を混同し、両方を同じ IP と考えてしまう。
- 「メールマガジン配信サーバ」も Web アクセスだと誤認し、x.y.z.102 を e に入れてしまう。
- 図1の「メールサーバ x.y.z.101」を選んでしまう(移行後は役割が変わるため誤り)。
FAQ
Q: 社員が社外から自宅回線などで Web メールを使う場合はどうなるのですか?
A: 手順1で「メール送受信ページにアクセス可能な接続元IPアドレス」を社内プロキシのみに限定しているので、社外からはアクセスできません。モバイル利用を想定するなら接続許可 IP を追加する必要があります。
A: 手順1で「メール送受信ページにアクセス可能な接続元IPアドレス」を社内プロキシのみに限定しているので、社外からはアクセスできません。モバイル利用を想定するなら接続許可 IP を追加する必要があります。
Q: 移行後、メールマガジン配信サーバからの送信が失敗するときの確認ポイントは?
A: クラウド側で「メール転送を許可する接続元IPアドレス」に「x.y.z.103」が登録されているか、SMTP 認証情報(利用者 ID・パスワード)が正しいかを確認します。
A: クラウド側で「メール転送を許可する接続元IPアドレス」に「x.y.z.103」が登録されているか、SMTP 認証情報(利用者 ID・パスワード)が正しいかを確認します。
Q: 現在のメールサーバを 2 週間残す理由は何ですか?
A: DNS キャッシュが残っている可能性があるためです。古い MX 情報を参照した相手先メールサーバが旧サーバへ投函したメールを受け取り、クラウドへ転送できるようにしています。
A: DNS キャッシュが残っている可能性があるためです。古い MX 情報を参照した相手先メールサーバが旧サーバへ投函したメールを受け取り、クラウドへ転送できるようにしています。
関連キーワード: プロキシサーバ、NAT, SMTP, IPフィルタリング、HTTPS
設問3:
本文中の下線①について、クラウドサービスを使ってメールマガジンを配信するために、メールマガジン配信サーバに必要な変更は何か。30字以内で述べよ。
模範解答
利用者IDとパスワードを用いた認証への対応
解説
解答の論理構成
-
変更対象が示されている箇所
【問題文】「手順5.①メールマガジン配信サーバに必要な変更を実施する。」
ここで“必要な変更”の内容を特定する必要があります。 -
クラウド側が要求する条件を確認
【問題文】「・a を用いたメール転送機能が利用可能である。この機能を利用する際は、利用者 ID とパスワードを用いた認証が必要である。」
メールマガジン配信サーバは従来どおり a(=SMTP)でメールを転送しますが、クラウドサービスでは SMTP 利用時に“利用者 ID とパスワードを用いた認証”が必須となります。 -
従来構成との差異を把握
現在のメールマガジン配信サーバは「中継用メールサーバとして “mail.p-sya.example.jp” が設定されており、メールは a を用いて、メールサーバへ送信」していました。旧メールサーバは社内設置で認証不要だったと読み取れます。 -
変更内容の導出
新クラウド環境では SMTP 転送を行うために“利用者 ID とパスワードを用いた認証”が必須です。したがって、メールマガジン配信サーバ側でこのSMTP 認証を行えるよう設定変更をすることが唯一の必須作業となります。 -
結論
以上より、メールマガジン配信サーバに対して行うべき変更は「利用者 ID とパスワードを用いた認証への対応」となります。
誤りやすいポイント
- 「宛先サーバの IP アドレスをクラウドサービスの IP に書き換える」とだけ答えてしまう
→ 宛先変更は DNS 切替で自動的に解決されるため、本設問で問われている“変更点”ではありません。 - 「TLS/SSL の導入」と答える
→ 問題文では SMTP 転送に対して“利用者 ID とパスワードを用いた認証”を必須と明記しており、暗号化の是非は問われていません。 - 「メールヘッダの From を変更」などアドレス周りの修正と誤解する
→ 方針に「現在のメールアドレスを継続利用」とあり、アドレス自体は変更しません。
FAQ
Q: SMTP 認証はなぜ必要なのですか?
A: クラウドサービスのメール転送機能は不正中継防止のために「利用者 ID とパスワード」を要求すると【問題文】で明示されています。認証がないとクラウド側が転送を拒否するため、配信サーバがメールを送れなくなります。
A: クラウドサービスのメール転送機能は不正中継防止のために「利用者 ID とパスワード」を要求すると【問題文】で明示されています。認証がないとクラウド側が転送を拒否するため、配信サーバがメールを送れなくなります。
Q: メールマガジン配信サーバからクラウドへの通信ポートは変更ありますか?
A: 説明ではプロトコルとして a(SMTP)を継続利用するとあるため、従来どおり TCP 25/587 等の SMTP ポートです。追加で必要なのは SMTP 認証に対応する設定だけです。
A: 説明ではプロトコルとして a(SMTP)を継続利用するとあるため、従来どおり TCP 25/587 等の SMTP ポートです。追加で必要なのは SMTP 認証に対応する設定だけです。
Q: DNS 切替後も旧サーバを 2 週間残す理由は?
A: DNS の TTL やキャッシュが残っている端末が旧サーバを参照する可能性があるため、移行期間中に受信したメールを取りこぼさないよう旧サーバを残し、受信したメールを「mail.p-sya.example.jp」へ転送させる必要があります。
A: DNS の TTL やキャッシュが残っている端末が旧サーバを参照する可能性があるため、移行期間中に受信したメールを取りこぼさないよう旧サーバを残し、受信したメールを「mail.p-sya.example.jp」へ転送させる必要があります。
関連キーワード: SMTP認証、メールリレー、認証方式、クラウド移行、セキュリティ対策
設問4:〔R課長のレビュー指摘〕について(1)、(2)に答えよ。
(1)現在のメールサーバがメールを受信する可能性があるのはなぜか。インターネット上のDNSサーバのキャッシュ情報に着目し、40字以内で述べよ。
模範解答
DNSサーバのキャッシュ情報が書き換わるのに時間を要するから
解説
解答の論理構成
- 【問題文】の手順3には「DNSサーバに登録してある mail.p-sya.example.jp の IPアドレスを、クラウドサービスの管理会社から通知された IPアドレスに変更する」とあります。
- しかし〔R課長のレビュー指摘〕では「移行後もしばらくは現在のメールサーバがメールを受信する可能性がある」と明言されています。
- その理由は、インターネット上の多数の DNS キャッシュサーバに旧 IP アドレスが残存しているためです。各キャッシュは TTL(有効期限)を迎えるまで情報を保持するので、期間中は外部の送信メールサーバが旧 IP アドレスへ配送を試みます。
- よって「DNSサーバのキャッシュ情報が書き換わるのに時間を要するから」が適切な解答となります。
誤りやすいポイント
- 「メールサーバが停止しているから」と逆の理由を想定してしまう
- DNS レコード変更=即時反映と考え、キャッシュの存在を失念する
- MX レコードの更新有無と A レコードの変更を混同する
- TTL を準備期間で短縮せず、本番移行時に慌てる設計ミス
FAQ
Q: TTL を短く設定すればキャッシュ問題は完全に解消できますか?
A: 事前に TTL を短縮すれば影響期間を縮められますが、全キャッシュが設定どおりに更新する保証はなく、短時間でも旧情報が残る可能性があります。
A: 事前に TTL を短縮すれば影響期間を縮められますが、全キャッシュが設定どおりに更新する保証はなく、短時間でも旧情報が残る可能性があります。
Q: 旧メールサーバを残す場合、どのような運用が必要ですか?
A: 旧サーバに届いたメールを新サーバへ転送する設定や、二重配送の検知・ログ監視が不可欠です。
A: 旧サーバに届いたメールを新サーバへ転送する設定や、二重配送の検知・ログ監視が不可欠です。
Q: キャッシュ更新遅延は Web サイト移行でも発生しますか?
A: はい。DNS を利用する全サービスに共通する問題で、Web サイトでもキャッシュが切り替わるまで旧 IP へアクセスが続きます。
A: はい。DNS を利用する全サービスに共通する問題で、Web サイトでもキャッシュが切り替わるまで旧 IP へアクセスが続きます。
関連キーワード: DNSキャッシュ、TTL, MXレコード、ネームリゾルバ、メール転送
設問4:〔R課長のレビュー指摘〕について(1)、(2)に答えよ。
(2)現在のメールサーバが受信したメールを転送する設定は〔メールサーバの移行手順案〕のどの手順の後に行う必要があるか。手順番号を答えよ。
模範解答
手順3
解説
解答の論理構成
-
R課長の指摘
- 【問題文】には「メールサーバが受信したメールをmail.p-sya.example.jpへ転送する設定を行う必要がある。」とあります。
- つまり、転送設定の送信先は mail.p-sya.example.jp に固定です。
-
転送先の IP アドレスが切り替わる手順
- 手順3 は「DNSサーバに登録してある mail.p-sya.example.jp の IPアドレスを、クラウドサービスの管理会社から通知された IPアドレスに変更する。」です。
- ここで初めて mail.p-sya.example.jp が旧メールサーバ(x.y.z.101)ではなくクラウド側の IP アドレスを指すようになります。
-
転送設定の実施タイミング
- 手順3 の前に転送設定を入れると、mail.p-sya.example.jp はまだ旧メールサーバ自身を指しているため、転送が自己ループになり機能しません。
- 手順3 の後なら mail.p-sya.example.jp がクラウドサービスを示すので、旧サーバが受信したメールを確実にクラウド側へ届けられます。
-
したがって、転送設定は「手順3」の後に行う必要があります。
誤りやすいポイント
- 手順2 直後と誤解する
- メールアドレス登録だけでは mail.p-sya.example.jp の向き先は変わらず、転送は自己宛てになります。
- 手順4 と混同する
- 手順4 は「メールボックスの全メールを移行」する作業で、リアルタイム転送とは別物です。
- 手順4 完了後に転送設定を忘れると、その後に届くメールがクラウドへ渡りません。
- “DNS 伝播待ち”を考慮し忘れる
- 手順3 の後も DNS キャッシュが残る可能性があるため、旧サーバは一定期間残すという R課長の指摘が重要です。
FAQ
Q: 手順3 後に転送設定をしても DNS の伝播遅延がある場合はどうなりますか?
A: 遅延中は一部の送信元が旧アドレスにメールを届けますが、旧サーバが転送設定を持っているのでクラウド側へ届きます。二重受信を防ぐために旧サーバ側でループしない設定を確認しましょう。
A: 遅延中は一部の送信元が旧アドレスにメールを届けますが、旧サーバが転送設定を持っているのでクラウド側へ届きます。二重受信を防ぐために旧サーバ側でループしない設定を確認しましょう。
Q: 転送設定では a(SMTP)認証が必要とありますが、旧サーバでも同じ認証を使うのですか?
A: はい。クラウド側は「a を用いたメール転送機能が利用可能である。この機能を利用する際は、利用者 ID とパスワードを用いた認証が必要である。」と定義されています。旧サーバでも認証情報を設定して SMTP 転送します。
A: はい。クラウド側は「a を用いたメール転送機能が利用可能である。この機能を利用する際は、利用者 ID とパスワードを用いた認証が必要である。」と定義されています。旧サーバでも認証情報を設定して SMTP 転送します。
Q: 旧サーバを残す期間は「2週間程度」で確定でしょうか?
A: 目安として提示されていますが、実際には DNS TTL や顧客のメールサーバ設定に応じて延長する場合があります。ログを監視し、旧サーバへの受信がなくなったことを確認してから撤去するのが安全です。
A: 目安として提示されていますが、実際には DNS TTL や顧客のメールサーバ設定に応じて延長する場合があります。ログを監視し、旧サーバへの受信がなくなったことを確認してから撤去するのが安全です。
関連キーワード: DNS切替、SMTP転送、メールループ、キャッシュ、フェールオーバー
設問5:
本文中の下線②について、PCが送信する大量メールの遮断に有効な、ファイアウォールに設定すべきルールはどれか。解答群の中から選び、記号で答えよ。
解答群
ア:宛先IPアドレスがPCのもので、宛先ポート番号が25番のIPパケットを遮断する。
イ:宛先IPアドレスがPCのもので、送元ポート番号が25番のIPパケットを遮断する。
ウ:送信元IPアドレスがPCのもので、宛先ポート番号が25番のIPパケットを遮断する。
エ:送信元IPアドレスがPCのもので、送元ポート番号が25番のIPパケットを遮断する。
模範解答
ウ
解説
解答の論理構成
-
想定される脅威を整理
下線②には
「PCがウイルスに感染した場合に、PCから社外へ大量のメールを送信する通信をファイアウォールで遮断することが可能となった」
とあります。ウイルスは SMTP を使って外部のメールサーバへ直接メール(ポート番号 25 番)をばらまくことが多いため、外向きの SMTP 通信を止める設定が必要です。 -
正常な通信との切り分け
〔メールサーバの移行方針〕では
「PC のメールソフトの利用は禁止し、Webブラウザを用いたメールの送受信に切り換える。Webブラウザとクラウドサービスの間の通信には、HTTPS を利用する。」
と明示されています。
したがって PC から外部へ必要なプロトコルは HTTPS(ポート番号 443 番)のみです。ポート番号 25 番を PC が利用する正当な理由はなくなりました。 -
ファイアウォールで止めるべきパケット
遮断対象は「送信元IPアドレスがPC」「宛先ポート番号が25番」。
・「送信元IPアドレスがPC」…PC からの外向きトラフィックであることを表す
・「宛先ポート番号が25番」…SMTP でメールを送ろうとしていることを表す -
選択肢との照合
ア 宛先IPアドレスがPC → インバウンドの制御なので不適
イ 宛先IPアドレスがPC+送元ポート25 → 同上
ウ 送信元IPアドレスがPC+宛先ポート25 → 上記要件に合致
エ 送信元IPアドレスがPC+送元ポート25 → 一般的に送元ポートは動的 (1024 以降) になるため誤りよって正解は「ウ」です。
誤りやすいポイント
- 送元ポートと宛先ポートの取り違え
SMTP では「宛先ポート番号が25番」です。送元側は大抵1024番以上の動的ポートになります。 - インバウンドとアウトバウンドの混同
「宛先IPアドレスがPC」のルールは外部から PC への通信を止める設定であり、本問の趣旨と逆方向です。 - 「メールソフト禁止だからポート25は使わない」と頭では分かっていても、実際のアクセス方向を図で確認しないまま選択肢を選ぶとミスしやすいです。
FAQ
Q: HTTPS だけ許可するとしても、DNS など他のポートは開けなくて良いのですか?
A: DNS 参照は通常プロキシサーバや社内 DNS を経由します。本問では PC から直接外部へ DNS 問い合わせを行う設定が示されていないため、SMTP 制御とは切り離して考えます。
A: DNS 参照は通常プロキシサーバや社内 DNS を経由します。本問では PC から直接外部へ DNS 問い合わせを行う設定が示されていないため、SMTP 制御とは切り離して考えます。
Q: ポート 587(Submission)は開けなくて良いのでしょうか?
A: 〔メールサーバの移行方針〕で「PC のメールソフトの利用は禁止」とされており、PC から直接メールを送信する経路は設けない前提です。必要になれば別途 587 番の運用ポリシーを決めて許可します。
A: 〔メールサーバの移行方針〕で「PC のメールソフトの利用は禁止」とされており、PC から直接メールを送信する経路は設けない前提です。必要になれば別途 587 番の運用ポリシーを決めて許可します。
Q: 送元ポート 25 番を遮断する設定は無意味なのですか?
A: ほとんどの OS はクライアント側でポート 25 番を送元ポートにしません。従って「送元ポートが25番」を条件にしても多くの不正メールは防げません。
A: ほとんどの OS はクライアント側でポート 25 番を送元ポートにしません。従って「送元ポートが25番」を条件にしても多くの不正メールは防げません。
関連キーワード: SMTP, ポート25, ファイアウォール、HTTPS, アウトバウンド制御


