🕊️

【AWS/RHEL9.6/Postfix/Dovecot】初心者向けメールサーバ構築記録 ~後編~

に公開

以下前編を読んでから本記事をご覧ください!
メールの仕組みに関する基礎知識や基盤環境の構築は以下記事にて行っています。
https://zenn.dev/gapteeth/articles/c715d0afecb95f

本記事の流れ

本記事の大まかな流れは以下の通りです。
■前編---------------
 1.メールサーバの役割を理解する
 2.AWS基盤構築
 3.CertbotからのSSL/TLS証明書取得
■後編/本記事---------------
 4.メールサーバ設定に必要な予備知識と事前準備
 5.Postfixの構築
 6.Dovecotの構築
 7.MTAサーバからのメール送信テスト
 8.Thunderbirdの構築
 9.その他
 10.おわりに

📖 4.メールサーバ設定に必要な予備知識と事前準備

📖 4-1.メールサーバの認証方式

前記事[1-2-3.25番ポートの制限(OP25B)について]で「MUAからMTAの接続時に認証(SMTP-AUTH)が必要になったことをお伝えしました。この後PostfixやDovecotの設定値を理解する上でもう少し認証の仕組みを理解する必要があるので、[4-1]では認証の仕組みについて記載していきます。

📖 4-1-1.認証の概要 ~SMTP-AUTHとSASL~

前提として、Postfixは認証機能を持たないので、実はMUAからMTAに接続して認証するときにPostfix単体では認証をすることができません。

そこでPostfixは認証の仕組み(プログラム)を持っているDovecotに認証をお願いします。このように、アプリケーションに他プログラムが認証を提供する仕組みのことをSASL(通称サスル)と呼びます。

次項ではSASLについてもう少し詳しく見ていきます。

📖 4-1-2.SASLとは

SASLには具体的に以下3つの役割があります。

  • 認証プログラムの選択
    Postfixなどのアプリケーションが自前で認証処理を持たない場合、代わりにDovecotやCyrus-SASLといった認証プログラム/サービス を選んで使える。(いずれも別途インストールが必要でRHELにあるものではありません。)Postfixで選択可能な認証プログラムはpostconf -aで確認できる。
    Postfixで利用可能な認証プログラム
    $ postconf -a
    cyrus
    dovecot
    
  • 認証メカニズムの選択
    クライアント⇔認証プログラム(今回はDovecot)間で認証情報(ユーザーID/パスワード等)をどのような方式でやり取りするかを選べる。今回はDovecotの設定値として登場する。
    例:PLAIN(平文)、CRAM-MD5(チャレンジレスポンス)、Kerberos(チケットベース、暗号化付き)、XOAUTH2(トークン認証)
  • 認証後の通信暗号化
    選択した認証の仕組みに暗号化が含まれる場合(Kerberos等)は、認証後の通信を暗号化できる。(本記事はTLS接続を用いて暗号化したり、Dovecotが上記仕組みを持たないことから"認証後の通信暗号化"は登場しません。)

次の項からはSASLの細かい通信の流れを見ていきましょう!

📖 4-1-3.ソケットファイルとは

まず、Postfix⇔Dovecot間の通信を細かく見ていきます。Postfix⇔Dovecot間の通信はソケットファイルと呼ばれるプロセス間で通信をするときのデータの出入り口となる特殊なファイルを介して行われます。 具体的には、Postfix⇔Dovecot間で認証の通信をするときに、/var/spool/postfix/private/authというパスのソケットファイルを介してデータをやり取りします。

補足として、ls -lでソケットファイルを確認すると先頭がsで表示されます。

ソケットファイルの表示
$ ls -l /var/spool/postfix/private/auth
srw-rw---- 1 postfix postfix 0 Jul 6 08:00 /var/spool/postfix/private/auth

後ほど、このソケットファイルのパスや権限を指定する設定値がPostfixとDovecotどちらでも出てきます!

📖 4-1-4.Dovecot内部の認証の流れ① ~デフォルトではPAM認証を利用~

次にPostfixがDovecotに認証を渡した後の流れを見ます。Dovecot内部ではPAM認証を利用していますが、本記事の本題からずれていくのでPAM認証の詳細な解説は割愛します。前提知識として、以下にPAM認証の分かりやすかった記事をご共有します。

具体的には、Dovecotデフォルトで/etc/pam.d/dovecotを読み込み認証を行います。本記事もこの認証方法を利用します。

デフォルトでは、Dovecot は PAM のサービス名として dovecot を使用するため、設定は /etc/pam.d/dovecot から読み込まれます。(🔗参考リンク:Dovecot/PAM/サービス名) ※筆者訳

📖 4-1-5.Dovecot内部の認証の流れ② ~PAM設定ファイル内部~

では、前項でお伝えした/etc/pam.d/dovecotを紐解き、「OSユーザーのID/PWで認証する」ということを明らかにしていきます。PAM認証ファイルを見ていくと以下の流れとなります。

  1. /etc/pam.d/dovecotの中身
    認証部分のみ着目していきます。タイプ(左から1列目)がauthである上から2行が認証関連ですね!1行目のpam_nologin.soは「/etc/nologinファイルがあればroot以外のユーザのログインを拒否する」モジュールなので、2行目でincludeして認証の実態となっているpassword-authの中身を次に覗きます。

    /etc/pam.d/dovecot
    $ cat /etc/pam.d/dovecot
    #%PAM-1.0
    auth       required     pam_nologin.so
    auth       include      password-auth
    account    include      password-auth
    session    include      password-auth
    

    ※Dovecot公式が出している/etc/pam.d/dovecotの例は文字通り"例"であり、デフォルト設定を保証するものではないようです。

  2. /etc/pam.d/password-authの中身
    /etc/pam.d/password-authは量が多いので、authタイプの部分のみ抜粋します。上から5行目に auth sufficient pam_unix.so nullok があり、ID/PWで認証が行われることが分かりますね!

    /etc/pam.d/password-auth
    $ cat /etc/authselect/password-auth
    # Generated by authselect on Fri Aug 15 15:59:11 2025
    # Do not modify this file manually.
    
    auth        required                                     pam_env.so
    auth        required                                     pam_faildelay.so delay=2000000
    auth        [default=1 ignore=ignore success=ok]         pam_usertype.so isregular
    auth        [default=1 ignore=ignore success=ok]         pam_localuser.so
    auth        sufficient                                   pam_unix.so nullok
    auth        [default=1 ignore=ignore success=ok]         pam_usertype.so isregular
    auth        sufficient                                   pam_sss.so forward_pass
    auth        required                                     pam_deny.so
    

    nullokなのでユーザーがPWを持たない場合は認証が通ってしまいます。必ずOSユーザーにPWを設定しましょう!

    また、1点補足ですが、password-authはシンボリックリンクとなっていて、ファイルの実態は/etc/authselect/system-authにあります。

    /etc/pam.d/password-auth
    $ ll /etc/pam.d/ | grep system-auth
    lrwxrwxrwx  1 root root  27 Aug 15 15:59 system-auth -> /etc/authselect/system-auth
    

📖 4-1-5.【まとめ】認証の流れ

ここまで触れた細かい部分も含めると以下の図のようになります!

📖 4-1-6.【発展】[4-1]参考文献

本記事では諸々簡潔に解説してしまいましたが、SASLやソケットファイルについてさらに深く知りたい方は自分が参考文献とした以下を読んでみてください!

📖 4-2.メールの保管方法

📖 4-2-1.Maildirとmailboxの違い

メールの保管方法も設定値として指定する必要があるので、メールの保管方法を理解しましょう!保管方法は主に以下2つあります。

  • Maildir
    あるディレクトリにメールファイルを配置していく。それぞれのメールファイルは個別に独立している。
  • mailbox
    1つのファイルに追記していくように、後から来たメールを1つのファイルにまとめていく。

    🔗参考リンク:Maildir形式【メール】

1つのファイルの中に全メールがあると読みにくいので、今回はMaildir形式を使用します!
他にもメール保管方法は多くあり、Dovecotではどのような方式をサポートしているか以下リンク内に記載があります。気になる方はご覧ください!

🔗参考リンク:Dovecot/メールボックスの形式

📖 4-2-2.Maildir方式のディレクトリ構成

Maildir方式のディレクトリは各ユーザーのホームディレクトリ配下に作られます。したがって、1章にてMRAを説明した時の図をさらに細かくすると以下のようになります。

さらに、OutlookやGmailも「新着」や「既読」があるように、Maildirディレクトリ配下に以下3つのディレクトリを設けます。

  • new:新着、未読のメッセージ
  • cur:既読メッセージ
  • tmp:配送処理中のメッセージ

したがって、メールボックスは以下図のようになり、これらのディレクトリを各ユーザー作成時に自動で作成されるよう設定する必要があります。

📖 4-3.ユーザー設定

認証とメール保管方法を通して、ユーザーに対して以下2点実施する必要があることが見えたと思います。本項ではこれらを1つずつ設定していきます。

  • ユーザーが作成されたときに/Maildir配下のディレクトリも自動的に作成できるように設定する。
  • PW認証を実施できるようにユーザーに対してPWを設定する。

📖 4-3-1.スケルトンディレクトリの設定

ユーザーが作成されたときに/Maildir配下のディレクトリも自動的に作成できるようにするためにスケルトンディレクトリを設定します。スケルトンディレクトリ(/etc/skel)とは、ユーザーのホームディレクトリ配下の雛形です。/etc/skel配下にディレクトリを作成することで、ユーザーを作成した時に自動的にホームディレクトリ配下にディレクトリを作成できます。

では、Maildir配下のディレクトリが自動作成されるようにスケルトンディレクトリを設定していきます。

スケルトンディレクトリ設定作業
### スケルトンディレクトリを設定する。
$ sudo mkdir -p /etc/skel/Maildir/{new,cur,tmp}

### 上記作成できたことを確認する。
$ ll /etc/skel/Maildir/
total 0
drwxr-xr-x 2 root root 6 Jul 21 16:10 cur
drwxr-xr-x 2 root root 6 Jul 21 16:10 new
drwxr-xr-x 2 root root 6 Jul 21 16:10 tmp

📖 4-3-2.ユーザーとPWの設定

PW認証を実施できるようにユーザーとPWを設定していきます。ユーザー名がメールアドレスのドメイン前に記載されます。ここではユーザー名をmaebaとします。

ユーザー作成
### ユーザーmaebaを作成する。
$ sudo useradd maeba -g wheel -u 1001

### maebaのPWを設定する。
$ sudo passwd maeba
Changing password for user maeba.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

### ユーザーmaebaのホームディレクトリ配下にMaildirディレクトリができたことを確認する。
$ sudo ls -l /home/maeba/
total 0
drwx------ 5 maeba wheel 39 Jul 21 16:10 Maildir

📖 4-4.SMTPコマンド

日頃メールをGUIでメールを作成していますが、実はそれらをCLI上のコマンドで行うことができます。次章ではそれらのコマンドに対してPostfixの設定で制限をかけるので、コマンドの役割と概要を理解しましょう!実際に次章でPostfixを設定した後に試験として実施してみることができます◎

📖 4-4-1.SMTPコマンドの役割概要

先にお伝えしたように、MUAの役割はメールサーバへ接続してメールを作成することまでです。それらをGUIで操作できるように簡略化したものがThunderbirdやOutlookです。例としては、以下のようにGUIが各コマンドが変換されていきます。

次項でその様子を見てみましょう!

📖 4-4-2.SMTPコマンドの種類と実行例

MUAからMTAヘ接続してメールを送信する一連の流れの例は以下の通りです。
コマンドの詳細は後述します。

メール送信実行例
$ openssl s_client -connect localhost:587 -quiet --starttls smtp
Connecting to 127.0.0.1
Can't use SSL_get_servername
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E5
verify return:1
depth=0 CN=mail.example.com
verify return:1
250 CHUNKING
EHLO maeba.example.com ###入力箇所###
250-mail.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
AUTH PLAIN [base64でエンコードした値を入れる] ###入力箇所###
235 2.7.0 Authentication successful
MAIL FROM:maeba@example.com ###入力箇所###
250 2.1.0 Ok
RCPT TO:okuba@gmail.com ###入力箇所###
250 2.1.5 Ok
DATA ###入力箇所###
354 End data with <CR><LF>.<CR><LF>
Subject:MatlTest To Gmail ###以降3行入力箇所###
Mail Todoitakana?
.
250 2.0.0 Ok: queued as 1B175868C46
QUIT ###入力箇所###
221 2.0.0 Bye

📖 4-4-3.SMTPコマンド解説

  • openssl s_client -connect [メールサーバのIPアドレスorホスト名]:587 -quiet --starttls
    MUAからMTAサーバへの接続コマンド。TLS通信を使わない時はTelnetになる。

    コマンド/オプション 説明
    openssl 証明書やTLS通信を行うコマンド。
    s_client SSL/TLS を使用してリモートホストに接続する。
    quiet セッション、証明書の出力を最小限にする。
    ※-quiet コマンドを付けずに実行すると数十行の証明書情報等が出力されます。
    connect host:port 接続するホストとポート番号を指定。
    starttls [protocol] 最初は平文で通信して途中からTLSに切り替えるプロトコルを指定する。以下のプロトコルに対応している:
    "smtp", "pop3", "imap", "ftp", "xmpp", "xmpp-server", "irc", "postgres", "mysql", "lmtp", "nntp", "sieve", "ldap"

    🔗参考リンク:openssl s_client(openssl公式)
    ※opensslコマンドはOpenSSLによって作られるOSSなので上記サイトで合っています。RHELがOpenSSLパッケージを利用しているイメージです。

  • depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
    信頼の連鎖の深さ(depth)やルート認証局、中間認証局(=CN)の情報を表している。詳細は以下リンク参照。

    🔗参考リンク:信頼の連鎖

  • verify return:1
    証明書の検証が問題なく成功したということ。応答されたコードにより検証失敗時の失敗の理由などが分かる。

  • 250 CHUNKING ~ 250 CHUNKING間各応答の意味
    前提として250という応答コードは"接続成功"や"機能利用可能"を示すものです。各応答で許可されている機能を端的にまとめると以下表の通りです。

    表示 説明 リンク
    250 CHUNKING メールサーバがメールメッセージを分割(チャンク)して送信できるSMTP拡張機能をサポートしていることを示している。大きな添付ファイルや長文メッセージでも、1つの通信で段階的に送信可能となり、パイプライン処理や途中送信エラーへの耐性を向上させる。 🔗参考リンク
    EHLO localhost SMTPセッション(メール作成等)を開始するコマンド。詳細は後述するコマンド一覧でまとめて記載。 🔗参考リンク
    250-mail.example.com SMTPクライアントとSMTPサーバーが初期状態(進行中のトランザクションが存在しない状態)なのでSMTPセッション可能。 🔗参考リンク
    250-PIPELINING 複数のSMTPコマンドを1つずつ待たずにまとめて送信するPIPELININGが可能である表示。MAIL FROMコマンドやDATAで応答を待たずにシェルスクリプトなどで一括してメールを送信することも可能。 🔗参考リンク
    250-SIZE 10240000 EHLO応答の SIZE キーワード値に数値パラメータが続く場合、それはサーバーが受け入れる最大メッセージサイズを示す。サイズ単位はバイトで10進数で表す。クライアントがこの制限を超えるメッセージを転送しようとした場合、失敗コード 552 によって拒否される。 🔗参考リンク
    250-ETRN サーバに保留されているメール配送をドメイン単位で指示するコマンドが利用可能である表示。クライアントが「ETRN <ドメイン>」を送ると、サーバはそのドメイン宛のメール配送を開始する。インターネットに常時接続できない時代に重宝された技術。現在は常時接続回線やモバイル通信が普及しており、実運用で利用されることはほぼない。 🔗参考リンク
    250-ENHANCEDSTATUSCODES 250のような拡張メール応答ステータスコードの拡張版(250 X.X.Xという形式)に対応していることを示す。拡張ステータスコードはRFC3463で定義されている。RCPT TOコマンド等の応答で使われる。 🔗参考リンク
    250-8BITMIME 8ビットデータ(日本語/画像/音声/PDF)をそのまま転送できることを示す。7ビットASCIIに限定されていた時代は日本語や画像などバイナリに近いデータは直接送れずエンコードが必要だった。8ビットデータをサポートすることでエンコード処理なしに直接送れるようになる。 🔗参考リンク
    250-DSN Delivery Status Notification(配信状況通知)をサポートしていることを示す。RCPT TOコマンドやMAIL FROMコマンドなどでオプションを指定することで、メール配送の成功/失敗の通知有無やその通知の情報量を指定できる機能。 🔗参考リンク
    250-AUTH PLAIN LOGIN SASLで可能な認証方式をAUTHに続いて表示する。各認証方式についてはDovecotの設定ファイル編集時にお伝えします。 🔗参考リンク
    250-SMTPUTF8 メールヘッダではASCII文字のみに制限されていたが、UTF-8エンコーディングを使用してメールヘッダにUnicode文字を含めること、及びそれをSMTPプロトコルを介して転送することが可能。 🔗参考リンク
    250 CHUNKING サーバーの応答の最後に拡張機能リストの終了を示すためにあると推察される。※RFCには明記されておらず、実装依存の可能性あり。 -
  • SMTP各コマンドの意味
    メール配送例に使用したコマンドの意味は以下の通りです。この後、Postfixの設定でmail fromコマンドやrcpt toコマンドに対して、宛先や送信元制限をかけます。

    コマンド 説明
    EHLO クライアントからサーバへSMTPセッションを開始する。
    AUTH PLAIN SASL認証を行う。235 2.7.0 Authentication successfulが出れば認証完了。ユーザ名\0ユーザ名\0パスワードをBASE64エンコードしたものを指定する。BASE64エンコードについては次項で後述。
    MAIL FROM: メール送信元を指定する。250が表示されれば正常に完了。
    RCPT TO: メール送信先を指定する。250が表示されれば正常に完了。
    DATA メール内容を書く。354は「メール入力を開始する。<CRLF>.<CRLF> で終了する。」という指示。※<CRLF>は改行の意味。Subjectでメール件名、from:で差出人(自由に記載可能)などを指定できる。
    QUIT SMTPセッションを終了する。(=メール送信する)221はSMTPセッションの終了を表す。

    🔗参考リンク/コマンド🔗参考リンク/応答コードの意味

📖 4-4-4.PWのBase64エンコード

先に記載したようにAUTH PLAINユーザ名\0ユーザ名\0パスワードをBASE64エンコードしたものを入力する必要があります。具体的には、ユーザー名maeba、パスワードmushibaのとき、以下コマンドで出力します。

$ printf "%s\0%s\0%s" maeba maeba mushiba | openssl base64 -e | tr -d '\n'; echo
bWFlYmEAbWFlYmEAbXVzaGliYQ==

コマンドやBase64についての参考資料は以下に置いておきます。本題から逸れるので詳細には解説しません。

※上記PWは実在するものではありません。本記事の例として実行しているものです。

🐭 5. Postfixの構築

🐭 5-1. Postfixのディレクトリ構成

Postfixで利用するファイルは/etc/postfix配下にあります。※以下は構築後のディレクトリ構成なので、バックアップ用に作成した末尾に日付がついたファイルがあります。

$ ll /etc/postfix/
total 260
-rw-r--r-- 1 root root 21111 Sep  8  2019 access
-rw-r--r-- 1 root root 13194 Jun  4  2018 canonical
-rw-r--r-- 1 root root    60 Jul 19  2024 dynamicmaps.cf
drwxr-xr-x 2 root root     6 Jul 19  2024 dynamicmaps.cf.d
-rw-r--r-- 1 root root 10221 Sep 17  2016 generic
-rw-r--r-- 1 root root 23802 Oct  9  2016 header_checks
-rw-r--r-- 1 root root 30905 Aug 21 07:12 main.cf
-rw-r--r-- 1 root root 29369 Jun 24 07:49 main.cf.20250721
-rw-r--r-- 1 root root 29130 Jul 19  2024 main.cf.proto
-rw-r--r-- 1 root root  6394 Jul 30 11:24 master.cf
-rw-r--r-- 1 root root  6382 Jul 30 10:25 master.cf.20250730
-rw-r--r-- 1 root root  6372 Jul 19  2024 master.cf.proto
-rw-r--r-- 1 root root 20163 Jul 19  2024 postfix-files
drwxr-xr-x 2 root root     6 Jul 19  2024 postfix-files.d
-rw-r--r-- 1 root root  6929 Feb 14  2016 relocated
-rw-r--r-- 1 root root 13436 Jan 11  2020 transport
-rw-r--r-- 1 root root 13963 Jun  4  2018 virtual

🐭 5-2. main.cfの設定編集

以下流れでコマンドを実行して、後述する設定値へ変更します。

### 設定ファイルのバックアップを作成する
$ sudo cp -piv /etc/postfix/main.cf{,_`date "+%Y%m%d"`}
'/etc/postfix/main.cf' -> '/etc/postfix/main.cf.20250721'

### main.cfを編集する。
$ sudo vi /etc/postfix/main.cf
 --------------------------
    後述する内容に変更する。
 --------------------------

### 変更内容に間違いないか確認する。
$ diff /etc/postfix/main.cf{,_`date "+%Y%m%d"`}

### 設定ファイルに構文ミスがないか確認する。
$ sudo postfix check

### Postfixのサービス再起動&設定ファイル反映はmaster.cfも終了後にまとめて行う想定。

🐭 5-2-1. main.cf設定値 ~メールサーバ基本設定~

  • 設定値:myhostname (🔗参考リンク)
    このメールサーバのインターネット上のホスト名(FQDN)を指定。

    【変更前】
    #myhostname = host.domain.tld
    #myhostname = virtual.domain.tld
    【変更後】
    #myhostname = host.domain.tld
    #myhostname = virtual.domain.tld
    myhostname = mail.example.com(追記)
    
  • 設定値:mydomain (🔗参考リンク)
    このメールシステムのインターネットドメイン名。デフォルトでは $myhostname から最初の要素を引いたものを使う。

    【変更前】
    #mydomain = domain.tld
    【変更後】
    #mydomain = domain.tld
    mydomain = example.com(追記)
    
  • 設定値:myorigin (🔗参考リンク)
    ローカルからのメール送信時、送信元メールアドレス@以降にドメイン名を補完する。

    【変更前】
    #myorigin = $myhostname
    #myorigin = $mydomain
    【変更後】
    #myorigin = $myhostname
    myorigin = $mydomain("#"外す)
    
  • 設定値:inet_interfaces (🔗参考リンク)
    メールを受信するIPアドレスを指定する。
    inet_interfaces = localhostのみだと127.0.0.1からしかメールを受け取れない。
    inet_interfaces = $myhostname, localhost、10.0.2.5でも意味は変わらないが、今後NICを追加した際に設定追加が必要になる。運用面を考慮せずに済むよう all を指定する。

    【変更前】
    #inet_interfaces = all
    #inet_interfaces = $myhostname
    #inet_interfaces = $myhostname, localhost
    inet_interfaces = localhost
    【変更後】
    inet_interfaces = all("#"外す)
    #inet_interfaces = $myhostname
    #inet_interfaces = $myhostname, localhost
    #inet_interfaces = localhost(コメントアウト)
    
  • 設定値:inet_protocols (🔗参考リンク)
    ipv4のみ使用する。(OSでipv6は無効化済)

    【変更前】
    inet_protocols = all
    【変更後】
    inet_protocols = ipv4
    
  • 設定値:mydestination (🔗参考リンク)
    指定ドメイン宛のメールをこのメールサーバで受信する。
    $mydomain(=example.com)ならばメールを受信する。

    【変更前】
    mydestination = $myhostname, localhost.$mydomain, localhost
    #mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
    #mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
    #mail.$mydomain, www.$mydomain, ftp.$mydomain
    【変更後】
    #mydestination = $myhostname, localhost.$mydomain, localhost(コメントアウト)
    mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain("#"外す)
    #mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
    #mail.$mydomain, www.$mydomain, ftp.$mydomain
    
  • 設定値:local_recipient_maps (🔗参考リンク)
    メール受信可能なユーザー名またはアドレスを記載したファイルを指定する。
    この設定は/etc/passwdもしくは/etc/aliasesを参照し、存在しないユーザー宛のメールは受信を拒否する。

    【変更前】
    #local_recipient_maps = unix:passwd.byname $alias_maps
    #local_recipient_maps = proxy:unix:passwd.byname $alias_maps
    #local_recipient_maps =
    【変更後】
    local_recipient_maps = unix:passwd.byname $alias_maps("#"外す)
    #local_recipient_maps = proxy:unix:passwd.byname $alias_maps
    #local_recipient_maps =
    
  • 設定値:mynetworks (🔗参考リンク)
    メール転送を許可する送信元CIDRを指定する。
    MTA⇒MTAのメール転送を想定(今回は不要だが送信可)。
    将来の検証や拡張性を考慮し、VPCと自分自身からの転送を許可する。

    【変更前】
    #mynetworks = 168.100.189.0/28, 127.0.0.0/8
    #mynetworks = $config_directory/mynetworks
    #mynetworks = hash:/etc/postfix/network_table
    【変更後】
    #mynetworks = 168.100.189.0/28, 127.0.0.0/8
    #mynetworks = $config_directory/mynetworks
    #mynetworks = hash:/etc/postfix/network_table
    mynetworks = 10.0.0.0/16, 127.0.0.0/8(追記)
    
  • 設定値:home_mailbox (🔗参考リンク)
    デフォルトのメールボックスファイルは/var/spool/mail/userまたは/var/mail/user。ユーザーのホームディレクトリからの相対パス名でメールボックスディレクトリを指定する。

    【変更前】
    #home_mailbox = Mailbox
    #home_mailbox = Maildir/
    【変更後】
    #home_mailbox = Mailbox
    home_mailbox = Maildir/("#"外す)
    
  • 設定値:smtpd_banner (🔗参考リンク)
    Telnet等でアクセスした際のバナー情報、バージョンを非表示にする。特定のミドルウェアバージョンや種類を狙った攻撃を防ぐ。

    【変更前】
    #smtpd_banner = $myhostname ESMTP $mail_name
    #smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
    【変更後】
    #smtpd_banner = $myhostname ESMTP $mail_name
    #smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
    smtpd_banner = $myhostname ESMTP(追記)
    

🐭 5-2-2. main.cf設定値 ~TLS通信の設定~

  • 設定値:smtpd_tls_key_file (🔗参考リンク)
    秘密鍵のパスを指定する。ファイルのパーミッションはrootユーザーに読み取り専用アクセスを許可し、その他のユーザーにはアクセスを許可しないことが推奨。

    【変更前】
    smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
    【変更後】
    smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
    
  • 設定値:smtpd_tls_cert_file (🔗参考リンク)
    サーバ証明書のパスを指定する。

    【変更前】
    smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
    【変更後】
    smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
    
  • 設定値:smtpd_tls_security_level (🔗参考リンク)
    メール受信時の通信暗号化についてのパラメータ。このパラメータは「smtpd_tls_wrappermode = yes 」(暗黙的TLS通信有効化)の場合無視される。次のいずれかのセキュリティレベルを指定する。

    • none:TLS通信無効化。
    • may:クライアントにSTARTTLSサポートを通知するが、STARTTLSを強制しない。(平文通信可)
    • encrypt:TLS暗号化の強制。RFC2487にて、公開SMTPサーバーへのこの設定適用は非推奨。submission(ポート587)などの専用サーバーで使用するならば可。
    【変更前】
    smtpd_tls_security_level = may(設定値があることを確認するのみ。変更なし)
    【変更後】
    -
    
  • 設定値:smtp_tls_security_level (🔗参考リンク)
    メール送信時の通信暗号化についてのパラメータ。(本サーバがクライアントの想定)次のいずれかのセキュリティレベルを指定する。

    • none:TLS通信無効化。
    • may:メールサーバがSTARTTLSサポートを通知するが、STARTTLSを強制しない。(平文通信可)
    • encrypt:TLS暗号化の強制。
    【変更前】
    smtp_tls_security_level = may(設定値があることを確認するのみ。変更なし)
    【変更後】
    -
    
  • 設定値:smtp_tls_loglevel (🔗参考リンク)
    メール送信時(=サーバがクライアントの時)のTLS通信のログ出力方法を指定する。デフォルトでTLS通信のログは記載されない。/var/log/maillogにログが出力される。

    • 0: 出力しない
    • 1: TLSハンドシェイクと証明書情報
    • 2: TLSネゴシエーションの全て(問題がある場合を除き、2以上の設定は非推奨)
    【変更前】
    デフォルトで記載なし
    【変更後】
    smtp_tls_loglevel = 1
    
  • 設定値:smtpd_tls_loglevel (🔗参考リンク)
    メール受信時のメールサーバのTLS通信のログ出力方法を指定する。デフォルトでTLS通信のログは記載されない。/var/log/maillogにログが出力される。

    • 0: 出力しない
    • 1: TLSハンドシェイクと証明書情報
    • 2: TLSネゴシエーションの全て(問題がある場合を除き、2以上の設定は非推奨)
    【変更前】
    デフォルトで記載なし
    【変更後】
    smtpd_tls_loglevel = 1
    

🐭 5-2-3. main.cf設定値 ~セキュリティ関連の設定~

  • 設定値:disable_vrfy_command (🔗参考リンク/公式, 🔗参考リンク/vrfyコマンド)
    SMTP接続時のvrfyコマンドを無効化する。vrfyコマンドはアカウントのメールボックスの存在を確認するコマンドであり、これを利用すると任意のアカウントの有無が分かってしまう。

    【変更前】
    デフォルトで記載なし
    【変更後】
    disable_vrfy_command = yes(追加)
    
  • 設定値:smtpd_helo_required (🔗参考リンク)
    メールクライアントが HELO コマンドまたは EHLO コマンドを使用してメール送信することを要求する。スクリプト化された迷惑メール等はSMTPのHELOコマンドを使用しないケースがあるため、それらのメールを拒否するために設定する。

    【変更前】
    デフォルトで記載なし
    【変更後】
    smtpd_helo_required = yes
    
  • 設定値:smtpd_client_restrictions (🔗参考リンク)
    SMTP接続の要求を受けた際に適用するアクセス制限。デフォルトでは全ての接続要求を許可。

    • reject_rbl_client(🔗参考リンク)
      メールクライアントのドメインをrbl_domainに問い合わせた結果A レコード(d.d.d.d)が存在する場合、そのSMTP接続を拒否する。以下設定値の場合は、zen.spamhaus.org(ブラックリスト)にドメインを問い合わせて逆引きでAレコードが帰ってきたら接続拒否する。
    • reject_unknown_client_hostname(🔗参考リンク)
      次の場合にリクエストを拒否する。
      ①クライアントIPアドレスからホスト名への逆引き(IP→名前)が失敗した場合
      ②クライアントホスト名からIPアドレスへの正引き(名前→アドレス)が失敗した場合
      ③名前→アドレスの結果がクライアントIPアドレスと一致しない場合
    【変更前】
    デフォルトで記載なし
    【変更後】
    smtpd_client_restrictions =
        reject_rbl_client zen.spamhaus.org,
        reject_unknown_client_hostname
    
  • 設定値:smtpd_helo_restrictions (🔗参考リンク)
    HELO/EHLOコマンド時に適用するアクセス制限。

    • reject_non_fqdn_helo_hostname (🔗参考リンク)
      指定ホスト名がFQDNでない場合接続を拒否する。smtpd_helo_required = yesの指定が必要。smtpd_helo_required = yesがない場合、クライアントは HELO または EHLO を送信しないことで reject_non_fqdn_helo_hostname を回避できる。
    【変更前】
    デフォルトで記載なし
    【変更後】
    smtpd_helo_restrictions =
        reject_non_fqdn_helo_hostname 
    
  • 設定値:smtpd_sender_restrictions (🔗参考リンク)
    MAIL FROMコマンド時に適用するアクセス制限。デフォルトでは全許可。

    • reject_rbl_sender(🔗参考リンク)
      MAIL FROMドメインをrbl_domainに問い合わせてAレコードが存在すれば、メール要求を拒否する。今回はzen.spamhaus.orgへ問い合わせを行い、SpamhausのブラックリストにIPアドレスが存在すればメールを拒否する。
    • reject_unknown_sender_domain(🔗参考リンク)
      Postfixが送信者アドレスの最終的な配送先ではなく、かつMAIL FROMドメインが以下のいずれかの場合にメール要求を拒否する。
      ①MAIL FROMドメインのDNSサーバに MX レコードも A レコードも存在しない場合
      ②MX ホスト名が長さゼロといった、不正な MX レコードが存在する場合
    • reject_non_fqdn_sender(🔗参考リンク)
      MAIL FROMアドレスがFQDNでない場合にメール要求を拒否する。
    【変更前】
    デフォルトで記載なし
    【変更後】
    smtpd_sender_restrictions =
        reject_rbl_sender zen.spamhaus.org,
        reject_unknown_sender_domain,
        reject_non_fqdn_sender
    
  • 設定値:smtpd_recipient_restrictions (🔗参考リンク)
    RCPT TOコマンド時に適用するアクセス制限。必ず次の制限のいずれかを含む必要がある。
    reject/reject_unauth_destination/defer/defer_if_permit/defer_unauth_destination

    • permit_sasl_authenticated(🔗参考リンク①/🔗参考リンク②)
      クライアントがSASL認証に成功していた場合、このアクセス制限対象から除外する。
    • reject_unauth_destination(🔗参考リンク)
      次のいずれかが真でなければメール要求を拒否する。
      ①Postfix がメールフォワーダーである場合
      RCPT TOコマンドで指定されたドメインが$relay_domainsまたはそのサブドメインに一致し、 かつ送信者指定のルーティング(user@elsewhere@domain)を含まない。
      ②Postfix が最終配送先である場合
      RCPT TOコマンドで指定されたドメインが$mydestination$inet_interfaces$proxy_interfaces$virtual_alias_domains、または$virtual_mailbox_domainsに一致し、かつ送信者指定のルーティング(user@elsewhere@domain)を含まない。
      ※送信者指定のルーティングとはuser@elsewhere@example.comのように@を複数含んでおり、宛先アドレスに余分な@が含まれ、送り主が経由するサーバを強制的に指定してしまう形の書き方のことです。
    • reject_non_fqdn_recipient(🔗参考リンク)
      RCPT TO アドレスで指定されたドメインがFQDNでない場合、メール要求を拒否する。
    【変更前】
    デフォルトで記載なし
    【変更後】
    smtpd_recipient_restrictions =
        permit_sasl_authenticated,
        reject_unauth_destination,
        reject_non_fqdn_recipient
    

🐭 5-2-3.【補足】設定値"~_restrictions"の挙動について

"~_restrictions"の具体的な挙動について2点詳細をお伝えします。

  1. メール送受信に関わる全ての場合が設定値の対象となる。
    Postfixにも以下のように色々な場面がありますが、接続の許可/拒否設定はいずれの場合でも適用されます。
    ・メールを送信するとき
    ・メールサーバとして25番ポートでメールを外部メールサーバから受信するとき
    ・587番ポートでMUAからメール送信を依頼されるとき

  2. smtpd_recipient_restrictions = permit_sasl_authenticatedを入れる理由
    「他設定値では許可設定を入れてないのに、なぜsmtpd_recipient_restrictionsのみ許可設定を入れているのか?」と疑問の思う方がいらっしゃると思います。
    実はsmtpd_recipient_restrictions = reject_unauth_destinationのみだと、VPC内部MUAから外部へメールを送信する時にRCPT TOコマンドの宛先が$relay_domainsに該当せず、メールを送信できません。(経験者は語る笑) そこで、smtpd_recipient_restrictions = permit_sasl_authenticatedを入れSASL認証をクリアしているならば宛先が外部でも送信できる設定としています。

🐭 5-2-4. main.cf設定値 SASL認証の設定~

  • 設定値:smtpd_sasl_auth_enable (🔗参考リンク)
    SASL認証を有効化する。デフォルトでは無効化されている。

    【変更前】
    デフォルトで記載なし
    【変更後】
    smtpd_sasl_auth_enable = yes
    
  • 設定値:smtpd_sasl_type (🔗参考リンク)
    認証に使用するSASLプラグイン(プログラム)の種類を指定する。

    【変更前】
    デフォルトで記載なし
    【変更後】
    smtpd_sasl_type = dovecot
    
  • 設定値:smtpd_sasl_path (🔗参考リンク)
    Dovecot SASL ライブラリの認証ソケットファイルを指定する。/var/spool/postfix/ からの相対パスで記述。

    【変更前】
    デフォルトで記載なし
    【変更後】
    smtpd_sasl_path = private/auth
    
  • 設定値:broken_sasl_auth_clients (🔗参考リンク)
    Microsoft Outlook Expressバージョン4やMicrosoft Exchangeバージョン5.0など廃止されたバージョンのAUTHコマンドとの相互運用性を有効にする。

    【変更前】
    デフォルトで記載なし
    【変更後】
    broken_sasl_auth_clients = yes
    

🐭 5-3. master.cfの設定編集

以下流れでコマンドを実行して、後述する設定値へ変更します。
また、設定ファイル内容は初見では読みにくいですが、以下公式リンクを読むと設定ファイル内容が理解できるようになってきます。(🔗master(5) manual page)

### 設定ファイルのバックアップを作成する
$ sudo cp -piv /etc/postfix/master.cf{,_`date "+%Y%m%d"`}
'/etc/postfix/master.cf' -> '/etc/postfix/master.cf.20250721'

### main.cfを編集する。
$ sudo vi /etc/postfix/master.cf
 --------------------------
    後述する内容に変更する。
 --------------------------

### 変更内容に間違いないか確認する。
$ diff /etc/postfix/master.cf{,_`date "+%Y%m%d"`}

### 設定ファイルに構文ミスがないか確認する。
$ sudo postfix check

### Postfixのサービス再起動&設定ファイル反映を行う。
$ sudo systemctl restart postfix
$ sudo systemctl status postfix

🐭 5-3-1. master.cfの設定編集

サブミッションポート(587番)の利用する設定とログの名前を設定します。

【変更前】
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (no)    (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd
…()#submission inet n       -       n       -       -       smtpd
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_tls_auth_only=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=
#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
【変更後】
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (no)    (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd
…()…
submission inet n       -       n       -       -       smtpd ("#"外す)
  -o syslog_name=postfix/submission ("#"外す)
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_tls_auth_only=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=
#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

🐭 5-3-2. master.cfの補足

master.cfのルールについて、以下2点補足します。

  • -o syslog_name=postfix/submission の具体例
    -o syslog_name=postfix/submission を設定することで、syslog の記録において、プロセス名の前に付加される形式を選択できます。例として、SASL認証時のログは以下のようになります。(🔗参考リンク)

    /var/log/maillog
    Sep  8 09:07:55 mta postfix/submission/smtpd[3420]: F3228868C46: client=localhost[127.0.0.1], sasl_method=PLAIN, sasl_username=maeba
    
  • master.cfはmain.cfの設定を上書きするもので、個別の設定ではない。
    具体的なポイントは以下2点です。

    • submissionの後ろにある-o ~はサブミッションポート(587番ポート)を利用する時のみmain.cfの設定より優先される設定値となる。

    • -o ~の設定値の意味が分らなかった場合、main.cf同様にpostconf(5)内に記載のある同じ名前の設定値が解説となる。

      -o { name = value }(ロング形式、Postfix 3.0 以降)
      指定された main.cf の設定パラメータを上書きします。
      パラメータ値は main.cf と同様に $name など他のパラメータを参照できます。
      構文については postconf(5) を参照してください。(🔗master(5) manual page) ※筆者訳

📮 6.Dovecotの構築

本章ではDovecotの設定ファイルを編集します。

📮 6-1. Dovecotの設定ファイルディレクトリ構成

dovecotで利用するファイルは/etc/dovecot配下にあります。

$ ll /etc/dovecot/
total 12
drwxr-xr-x 2 root root 4096 Jul  8 07:22 conf.d
-rw-r--r-- 1 root root 4333 Aug  6  2021 dovecot.conf
$ ll /etc/dovecot/conf.d/
total 128
-rw-r--r-- 1 root root  5248 Aug  6  2021 10-auth.conf
-rw-r--r-- 1 root root  1781 Aug  6  2021 10-director.conf
-rw-r--r-- 1 root root  3757 Aug  6  2021 10-logging.conf
-rw-r--r-- 1 root root 17795 Feb  6 02:35 10-mail.conf
-rw-r--r-- 1 root root  3569 Aug  6  2021 10-master.conf
-rw-r--r-- 1 root root  1585 Aug  6  2021 10-metrics.conf
-rw-r--r-- 1 root root  3648 Feb  6 02:36 10-ssl.conf
-rw-r--r-- 1 root root  1657 Aug  6  2021 15-lda.conf
-rw-r--r-- 1 root root  3111 Aug  6  2021 15-mailboxes.conf
-rw-r--r-- 1 root root  4520 Aug  6  2021 20-imap.conf
-rw-r--r-- 1 root root  1367 Aug  6  2021 20-lmtp.conf
-rw-r--r-- 1 root root  4066 Aug  6  2021 20-pop3.conf
-rw-r--r-- 1 root root  4299 Aug  6  2021 20-submission.conf
-rw-r--r-- 1 root root   676 Aug  6  2021 90-acl.conf
-rw-r--r-- 1 root root   292 Aug  6  2021 90-plugin.conf
-rw-r--r-- 1 root root  2596 Aug  6  2021 90-quota.conf
-rw-r--r-- 1 root root   499 Aug  6  2021 auth-checkpassword.conf.ext
-rw-r--r-- 1 root root   489 Aug  6  2021 auth-deny.conf.ext
-rw-r--r-- 1 root root   343 Aug  6  2021 auth-dict.conf.ext
-rw-r--r-- 1 root root   924 Aug  6  2021 auth-ldap.conf.ext
-rw-r--r-- 1 root root   561 Aug  6  2021 auth-master.conf.ext
-rw-r--r-- 1 root root   515 Aug  6  2021 auth-passwdfile.conf.ext
-rw-r--r-- 1 root root   788 Aug  6  2021 auth-sql.conf.ext
-rw-r--r-- 1 root root   611 Aug  6  2021 auth-static.conf.ext
-rw-r--r-- 1 root root  2182 Aug  6  2021 auth-system.conf.ext

📮 6-2. dovecotの設定編集

📮 6-2-1. 設定ファイル編集の操作

この後合計5つの設定ファイルを修正しますが、以下作業が設定ファイル前後で繰り返し行われているものとします。重複するのでここにまとめて記載します。

### 設定ファイルのバックアップをとる。
$ sudo cp -piv /etc/dovecot/[設定ファイル名]{,.`date "+%Y%m%d"`}
'/etc/dovecot/[設定ファイル名]' -> '/etc/dovecot/[設定ファイル名].[日付]'

### 設定ファイルを編集する。
$ sudo vi /etc/dovecot/[設定ファイル名]
   --------------
   後述する内容に修正する。
   --------------

### 設定ファイルの編集内容を確認する。
$ diff /etc/dovecot/[設定ファイル名]{,.`date "+%Y%m%d"`}

📮 6-2-2. 10-mail.confの設定編集

  • 設定値:mail_location(🔗参考リンク①/🔗参考リンク②)
    • デフォルトでmail_location設定は空になっていて、Dovecotは以下の項目を順番に確認することでメールボックスの場所を自動的に特定しようとする。
      ~/mdbox/
      ~/sdbox/
      ~/Maildir/
      …(略)…
    • メールボックスの場所の指定の形式は次のとおり。
      <mailbox-format> : <path>
    • ~/ はそのユーザーのホームディレクトリを指し、Dovecotが自動で展開する。
    【変更前】
    #mail_location =
    【変更後】
    mail_location = maildir:~/Maildir
    

📮 6-2-3. 10-master.confの設定編集

  • 設定値:unix_listener(🔗参考リンク(SASL認証の設定)/🔗参考リンク(unix_listener))
    SASL認証に利用するソケットファイル(var/spool/postfix/private/auth)の権限や所有者をPostfixに指定して、Postfixがアクセスできるようにする。

    【変更前】
    service auth {()# Postfix smtp-auth
        #unix_listener /var/spool/postfix/private/auth {
        #  mode = 0666
        #}
    }
    【変更後】
     service auth {()# Postfix smtp-auth
        unix_listener /var/spool/postfix/private/auth {("#"外す)
           mode = 0666("#"外す)
           user = postfix(追記)
           group = postfix(追記)
        }("#"外す)
     }
    
  • 設定値:inet_listener(🔗参考リンク)
    プロトコルで使用するポート番号、SSL化の有無などを指定します。port=0はサービスの無効化を意味する。imapは使用しないので無効化する。

    【変更前】
    service imap-login {
      inet_listener imap {
        #port = 143
      }
      inet_listener imaps {
        #port = 993
        #ssl = yes
      }()}
    【変更後】
    service imap-login {
      inet_listener imap {
        #port = 143
        port = 0(追記)
      }
      inet_listener imaps {
      port = 993("#"外す)
      ssl = yes("#"外す)
      }()}
    

📮 6-2-4. 10-auth.confの設定編集

  • 設定値:disable_plaintext_auth(🔗参考リンク)
    yesの場合は平文での認証を拒否する。noの場合は平文での認証を許可する。平文での認証(以下引用内「PLAINメカニズム」)を行うが通信自体を暗号化する対策を取る。Dovecot公式には以下のように見解が記載されている。認証のメカニズムは次の設定値で触れる。

    SSLで保護された接続内で暗号化されていないパスワードを送信しても問題はありません。したがって、SSLを使用している場合は、PLAINメカニズム以外のことを気にする必要はおそらくないでしょう。 ※筆者訳

    【変更前】
    #disable_plaintext_auth = yes
    【変更後】
    disable_plaintext_auth = no
    
  • 設定値:auth_mechanisms(🔗参考リンク(PLAIN認証)/🔗参考リンク(LOGIN認証))
    plainは平文での認証。loginはSMTPサーバーがOutlookクライアントにSMTP認証を実行させるためにのみ使用される。LOGINコマンドは内部的にPLAINメカニズムを使用して処理される。
    【変更前】
    auth_mechanisms = plain
    【変更後】
    auth_mechanisms = plain login (追記)
    
    その他の認証が気になる場合は以下リンク参照。

    🔗参考リンク/非平文認証

📮 6-2-5. 10-ssl.confの設定編集

  • 設定値:ssl(🔗参考リンク)
    この設定値は10-authdisable_plaintext_authと一緒に設定値の意味を考える必要がある。
    • ssl=no
      SSL/TLS は完全に無効。
    • ssl=yesおよびdisable_plaintext_auth=no
      クライアントにはSSL/TLSが提供されているが、クライアントはそれを使用する義務がない。接続時にSSL/TLSが有効になっていない場合でも、クライアントは平文認証でログインできる。
    • ssl=yesおよびdisable_plaintext_auth=yes
      クライアントにはSSL/TLSが提供されているが、クライアントはそれを使用する義務がない。SSL/TLSが事前に有効化されていない限り、クライアントは平文認証を使用できない。
    • ssl=required
      非平文認証メカニズムを使用する場合でも、SSL/TLSは常に必須。SSL/TLSが有効になる前に認証を試みると認証に失敗する。暗黙的なSSL/TLSまたはSTARTTLSコマンドのいずれかが許可される。
    【変更前】
    ssl = required
    【変更後】
    ssl = yes
    
  • 設定値:ssl_cert/ssl_key(🔗参考リンク)
    ssl_certは証明書のパスを指定する。ssl_certは秘密鍵のパスを指定する。
    【変更前】
     ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
     ssl_key = </etc/pki/dovecot/private/dovecot.pem
    【変更後】
     ssl_cert = </etc/letsencrypt/live/mail.example.com/fullchain.pem
     ssl_key = </etc/letsencrypt/live/mail.example.com/privkey.pem
    

📮 6-2-6. 設定ファイル修正の反映

設置ファイルの構文チェックをします。エラーについては、Dovecot公式に以下の記載があります。したがって、以下エラー以外が出なければ問題ないです。

### 構文チェックを行う
$ dovecot -n
# 2.3.16 (7e2e900c1a): /etc/dovecot/dovecot.conf
# OS: Linux 5.14.0-570.12.1.el9_6.x86_64 x86_64 Red Hat Enterprise Linux release 9.6 (Plow)
# Hostname: mta
doveconf: Error: ssl enabled, but ssl_dh not set

バージョン 2.3.3 以降では、必要なのは ssl_key と ssl_cert だけです。
ssl_dh を未設定のままにし(さらに 2.2 の設定から残っている場合は ssl-parameters.dat を削除することで)、非 EC DH アルゴリズムの使用を防止できます。(Dovecot公式/SSL とプレーンテキスト認証)

最後にサービスの再起動を行います。

### dovecotの設定編集を反映させるためにサービス再起動をする。
$ sudo systemctl restart dovecot
### エラーが出ていないか確認する。
$ sudo systemctl status dovecot

🚚 7.MTAサーバからのメール送信テスト

MTAサーバのみを用いてメールの送受信テストを行ってみましょう!

🚚 7-1. メールテストの準備

🚚 7-1-1. 587番ポートが空いていることの確認

ssコマンドで25/587/993番ポートがLISTEN(接続待ち)であることを確認します。また、110/143で何も表示されなず(ポートが使われておらず)Dovecotの設定通りであることを確認します。

$ ss -atn | grep 25
LISTEN 0      100          0.0.0.0:25           0.0.0.0:*
 
$ ss -atn | grep 587
LISTEN 0      100          0.0.0.0:587          0.0.0.0:*

$ ss -atn | grep 993
LISTEN 0      100          0.0.0.0:993          0.0.0.0:*

$ ss -atn | grep 110 ###実行結果が何も表示されない###

$ ss -atn | grep 143 ###実行結果が何も表示されない###

※本記事ではEC2のSGで許可設定を管理しており、管理が煩雑になることを防ぐためにRHELのFirewallでは通信制限をかけていません。念のために確認している意味合いもあります。

🚚 7-1-2. IMAPコマンドの使い方

以下2つの記事が分かりやすく解説してくださっていたので、本記事でのIAMPコマンドの紹介は割愛します。

IMAP4(Internet Mail Access Protocol version 4)~前編
IMAP4(Internet Mail Access Protocol version 4)~後編

🚚 7-2. 自分自身へメールを送信する

🚚 7-2-1. メールの送信

$ openssl s_client -connect localhost:587 -quiet --starttls smtp
Connecting to 127.0.0.1
Can't use SSL_get_servername
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E5
verify return:1
depth=0 CN=mail.example.com
verify return:1
250 CHUNKING
EHLO maeba.example.com ###入力箇所###
250-mail.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
AUTH PLAIN [base64でエンコードしたもの] ###入力箇所###
235 2.7.0 Authentication successful
MAIL FROM:maeba@example.com ###入力箇所###
250 2.1.0 Ok
RCPT TO:maeba@example.com ###入力箇所###
250 2.1.5 Ok
DATA ###入力箇所###
354 End data with <CR><LF>.<CR><LF>
Subject:MailTest To Me! ###以下3行入力箇所###
MailTest To Me!
.
250 2.0.0 Ok: queued as 2285C868AC5
QUIT
221 2.0.0 Bye

🚚 7-2-2. メールの受信確認

メールが受信できていることをIMAPのコマンドを用いて確認します。

$ openssl s_client -quiet -connect localhost:993
Connecting to 127.0.0.1
Can't use SSL_get_servername
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E5
verify return:1
depth=0 CN=mail.example.com
verify return:1
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
1 login maeba [maebaのパスワード] ###入力箇所###
1 OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS …()] Logged in
2 LIST "" * ###入力箇所###
* LIST (\HasNoChildren \UnMarked \Trash) "." Trash
* LIST (\HasNoChildren) "." INBOX
2 OK List completed (0.006 + 0.000 + 0.005 secs).
3 SELECT INBOX ###入力箇所###
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 27 EXISTS
* 1 RECENT
* OK [UNSEEN 22] First unseen.
* OK [UIDVALIDITY 1754274320] UIDs valid
* OK [UIDNEXT 33] Predicted next UID
3 OK [READ-WRITE] Select completed (0.007 + 0.000 + 0.006 secs).
4 SEARCH ON 09-Sep-2025 UNSEEN ###入力箇所/該当の日付に受信してまだ未読のメールを探す###
* SEARCH 27
4 OK Search completed (0.001 + 0.000 secs).
5 FETCH 27 BODY[] ###入力箇所/SEARCHの結果を入力する###
* 27 FETCH (FLAGS (\Seen \Recent) BODY[] {505}
Return-Path: <maeba@example.com>
X-Original-To: maeba@example.com
Delivered-To: maeba@example.com
Received: from maeba.example.com (localhost [127.0.0.1])
        by mail.example.com (Postfix) with ESMTPSA id 2285C868AC5
        for <maeba@example.com>; Tue,  9 Sep 2025 08:45:41 +0900 (JST)
Subject:MailTest To Me!
Message-Id: <20250908234602.2285C868AC5@mail.example.com>
Date: Tue,  9 Sep 2025 08:45:41 +0900 (JST)
From: maeba@example.com

MailTest To Me!
)
5 OK Fetch completed (0.004 + 0.000 + 0.003 secs).
6 LOGOUT ###入力箇所###
* BYE Logging out
6 OK Logout completed (0.001 + 0.000 secs).

🚚 7-3. 外部(Gmail)へメールを送信する

本記事記載用に構築後に改めてメール送信したのでテスト日時が前後することがありますが、コマンドの内容は変わらないのでご容赦ください!

🚚 7-3-1. メールの送信 ~MTAサーバ側~

打つコマンドはほぼ同じですが、宛先のRCPT TOコマンドの対象を外部のGmailへ変更します。

$ openssl s_client -connect localhost:587 -quiet --starttls smtp
Connecting to 127.0.0.1
Can't use SSL_get_servername
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E5
verify return:1
depth=0 CN=mail.example.com
verify return:1
250 CHUNKING
EHLO maeba.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
AUTH PLAIN [base64でエンコードした値を入れる]
235 2.7.0 Authentication successful
MAIL FROM:maeba@example.com
250 2.1.0 Ok
RCPT TO:okuba@gmail.com
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject:MatlTest To Gmail
Mail Todoitakana?
.
250 2.0.0 Ok: queued as 1B175868C46
QUIT
221 2.0.0 Bye

🚚 7-3-2. メールの送信 ~Gmail側~

Gmail側でメールが届いていることを確認します。

続いてSPFレコードが認証されていることを確認します。メール右上の3つの点を選択し、[原文を表示]を選択します。

SPFの行が「PASS」となっていればSPFの認証が通っています!

🚚 7-3-3. メールの受信 ~Gmail側~

では、Gmailから先ほどのメールに返信して、MTAサーバが受信できるか試してみましょう!
Gmailを受信した時にTLS通信を確立できているか調べたいので、MTAサーバ側でsudo tail -f /var/log/maillogを実行してからGmailからメールを返信しておきます!

🚚 7-3-2. メールの受信 ~MTAサーバ側~

メールをGmailから送信すると/var/log/maillogにメールを受信したログが出力されます。
要点を大まかに説明すると以下の通りです。

  • Anonymous TLS connection established from mail-pl1-f179.google.com[209.85.214.179]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
    TLS通信がGmail側MTAサーバと確立された。
  • from=<okuba@gmail.com>, size=4052, nrcpt=1 (queue active)
    okuba@gmail.comからメールを受信した。
  • to=<maeba@example.com>, relay=local, delay=0.03, delays=0.01/0.01/0/0, dsn=2.0.0, status=sent (delivered to maildir)
    maeba@example.com宛てのメールを受信した。status=sentならばメール送受信が無事に完了している。status=bouncedは「送信失敗」、status=deferredは「一時的に配送不可のため再送」を表している。
  • disconnect from mail-pl1-f179.google.com[209.85.214.179] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1 quit=1 commands=7
    Gmail側MTAサーバで記載のコマンドが数字の回数だけ実行された。Gmail側MTAサーバから構築したMTAサーバへSTARTTLSコマンドが実行されていることが分かる。commandsの後ろの数字は実行されたコマンドの数を表している。
/var/log/maillog
Sep  8 08:25:36 mta postfix/smtpd[1511]: Anonymous TLS connection established from mail-pl1-f179.google.com[209.85.214.179]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
Sep  8 08:25:37 mta postfix/smtpd[1511]: 18966868C46: client=mail-pl1-f179.google.com[209.85.214.179]
Sep  8 08:25:37 mta postfix/cleanup[1823]: 18966868C46: message-id=<CAFsnQvOOQCqP8--MWL5Vd7xAoqba9bMkvo6xDfZsjOT9edqCFg@mail.gmail.com>
Sep  8 08:25:37 mta postfix/qmgr[1028]: 18966868C46: from=<okuba@gmail.com>, size=4052, nrcpt=1 (queue active)
Sep  8 08:25:37 mta postfix/local[1824]: 18966868C46: to=<maeba@example.com>, relay=local, delay=0.03, delays=0.01/0.01/0/0, dsn=2.0.0, status=sent (delivered to maildir)
Sep  8 08:25:37 mta postfix/qmgr[1028]: 18966868C46: removed
Sep  8 08:25:37 mta postfix/smtpd[1511]: disconnect from mail-pl1-f179.google.com[209.85.214.179] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1 quit=1 commands=7

詳細なログの読み方は以下をご覧ください!

Postfixのメールログの探し方・読み方・使い方を解説

続いて、メールの受信を確認します。無事にメールの受信を確認できました!

$ openssl s_client -quiet -connect localhost:993
Connecting to 127.0.0.1
Can't use SSL_get_servername
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E5
verify return:1
depth=0 CN=mail.example.com
verify return:1
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
1 login maeba [ユーザのパスワード] ###入力箇所###
1 OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE …()] Logged in
2 LIST "" * ###入力箇所###
* LIST (\HasNoChildren \UnMarked \Trash) "." Trash
* LIST (\HasNoChildren) "." INBOX
2 OK List completed (0.003 + 0.000 + 0.002 secs).
3 SELECT INBOX ###入力箇所###
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 25 EXISTS
* 2 RECENT
* OK [UNSEEN 22] First unseen.
* OK [UIDVALIDITY 1754274320] UIDs valid
* OK [UIDNEXT 31] Predicted next UID
3 OK [READ-WRITE] Select completed (0.007 + 0.000 + 0.006 secs).
4 SEARCH ON 08-Sep-2025 UNSEEN ###入力箇所/該当の日付に受信してまだ未読のメールを探す###
* SEARCH 25
4 OK Search completed (0.002 + 0.000 + 0.001 secs).
5 FETCH 25 BODY[]  ###入力箇所###
* 25 FETCH (FLAGS (\Seen \Recent) BODY[] {4181}
Return-Path: <okuba@gmail.com>
X-Original-To: maeba@example.com
Delivered-To: maeba@example.com
Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179])
        by mail.example.com (Postfix) with ESMTPS id 18966868C46
        for <maeba@example.com>; Mon,  8 Sep 2025 08:25:37 +0900 (JST)
Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-24b21006804so38693045ad.3
        for <maeba@example.com>; Sun, 07 Sep 2025 16:25:37 -0700 (PDT)()…
MIME-Version: 1.0
References: <20250907232001.1B175868C46@mail.example.com>
In-Reply-To: <20250907232001.1B175868C46@mail.example.com>
From: Okuba <okuba@gmail.com>
Date: Mon, 8 Sep 2025 08:25:25 +0900
X-Gm-Features: Ac12FXyaGW-HJpLheUfNs_iNgFhvK3DTWNSbhe8Q9-UnI4BdG5fihZIA-uRmic8
Message-ID: <CAFsnQvOOQCqP8--MWL5Vd7xAoqba9bMkvo6xDfZsjOT9edqCFg@mail.gmail.com>
Subject: Re: MatlTest To Gmail
To: maeba@example.com
Content-Type: multipart/alternative; boundary="00000000000051da4f063e3e6322"

--00000000000051da4f063e3e6322
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Todoitayo-----------------!!!

2025=E5=B9=B49=E6=9C=888=E6=97=A5(=E6=9C=88) 8:22 <maeba@example.com>=
:

> Mail Todoitakana?
>

--00000000000051da4f063e3e6322
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

…())
5 OK Fetch completed (0.004 + 0.000 + 0.003 secs).
6 LOGOUT  ###入力箇所###
* BYE Logging out
6 OK Logout completed (0.001 + 0.000 secs).

ここまでくればメールサーバとしての機能は完成したので、あとはメールサーバに接続するMUAとなるサーバを構築するのみです!

📧 8.Thunderbirdの構築

前編の前提条件記載の通りWindowsServer2025にて以下を実施していきます。

📧 8-1. Thunderbirdのインストール

  1. 以下リンクへアクセスして画面中央[ダウンロード]を押下する。
    ▷Thudnerbirdダウンロードリンク:https://www.thunderbird.net/ja/


  2. ダウンロードしたThunderbirdのEXEファイルをクリックしてセットアップを開始する。

  3. 特別な設定はないですが、セットアップの内容を置いておきます。






📧 8-2. Thunderbirdの初期設定

続いてThudnerbirdを起動すると表示される初期設定画面でMTAサーバの設定をMUAであるThunderbirdに入れていきます。

  1. Thunderbirdで用いるユーザー名とパスワードを入力します。
  2. 受信サーバーにはDovecotの設定を入れます。
  3. 送信サーバーにはPostfixの設定を入れる。
  4. 送信サーバー設定の右下にある[完了]を押す。
  5. アカウント作成の完了画面が表示されます。画面下にある[完了]を押す。
  6. メールクライアントとして設定するので[メール]を選択して、[規定として設定]を選択します。
  7. メールを作成したり、閲覧したりする画面になればThunderbirdの設定完了です!

📧 8-3. Thunderbirdでのメール動作試験

📧 8-3-1.Dovecotへの接続

/var/log/maillogにてログの確認を行うので事前にMTAサーバにてsudo tail -f /var/log/maillogを実行してください。
1回ThunderBirdを再起動するとパスワードの入力を求められると思います。

認証されていることが、以下ログから分かります。

/var/log/maillog
### 10.0.2.5がMTAサーバ
### 10.0.2.6がMUAサーバ
$ sudo tail -f /var/log/maillog
Aug 11 19:26:55 mta dovecot[1099]: imap-login: Login: user=<maeba>, method=PLAIN, rip=10.0.2.5, lip=10.0.2.6, mpid=3713, TLS, session=<HlLaXBQ8r8IKAIAK>
Aug 11 19:26:55 mta dovecot[1099]: imap-login: Login: user=<maeba>, method=PLAIN, rip=10.0.2.5, lip=10.0.2.6, mpid=3725, TLS, session=<+GveXBQ8sMIKAIAK>

📧 8-3-2.Gmailへのメール送信

  1. Gmail(okuba@gmail)宛てのメールを作成します。
  2. ポップアップ画面で認証を求められるのでパスワードを入れ[OK]押下しメールを送信します。PostfixのSASL認証が機能していますね!
    /var/log/maillog
    $ sudo tail -f /var/log/maillog
    Aug 11 19:28:53 mta postfix/submission/smtpd[3726]: 08D34868E00: client=ip-10.0.2.6.ap-northeast-2.compute.internal[10.0.2.6], sasl_method=PLAIN, sasl_username=maeba
    Aug 11 19:28:53 mta postfix/cleanup[3732]: 08D34868E00: message-id=<6289f6bb-7196-4b82-9712-513037fb1f84@example.com>
    Aug 11 19:28:53 mta postfix/qmgr[1022]: 08D34868E00: from=<maeba@example.com>, size=649, nrcpt=1 (queue active)
    Aug 11 19:28:53 mta postfix/smtp[3733]: Trusted TLS connection established to aspmx.l.google.com[64.233.189.27]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
    Aug 11 19:28:54 mta postfix/smtp[3733]: 08D34868E00: to=<okuba@gmail.com>, relay=aspmx.l.google.com[64.233.189.27]:25, delay=1.9, delays=0.02/0.02/1.1/0.78, dsn=2.0.0, status=sent (250 2.0.0 OK  1754908134 98e67ed59e1d1-3216128e91fsi14442833a91.18 - gsmtp)
    Aug 11 19:28:54 mta postfix/qmgr[1022]: 08D34868E00: removed
    Aug 11 19:28:58 mta postfix/submission/smtpd[3726]: disconnect from ip-10.0.2.6.ap-northeast-2.compute.internal[10.0.2.6] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8
    
  3. Gmail側でメールが届いたことを確認します。

📧 8-3-3.Gmailからのメール受信

  1. Gmail(okuba@gmail)側で返信するメールを作成して送信します。
  2. Thunderbirdでメールの受信を確認します。
    /var/log/maillog
     $ sudo tail -f /var/log/maillog
     Aug 11 19:31:07 mta postfix/smtpd[3705]: Anonymous TLS connection established from mail-pl1-f179.google.com[209.85.214.179]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
     Aug 11 19:31:08 mta postfix/smtpd[3705]: 3C8EF868E00: client=mail-pl1-f179.google.com[209.85.214.179]
     Aug 11 19:31:08 mta postfix/cleanup[3736]: 3C8EF868E00: message-id=<CAFsnQvNzcFW++BfDBP5VfOzcTj8Nm-GKpZ3uNysmbTDQpqvGQQ@mail.gmail.com>
     Aug 11 19:31:08 mta postfix/qmgr[1022]: 3C8EF868E00: from=<okuba@gmail.com>, size=4144, nrcpt=1 (queue active)
     Aug 11 19:31:08 mta postfix/local[3737]: 3C8EF868E00: to=<maeba@example.com>, relay=local, delay=0.02, delays=0.01/0.01/0/0, dsn=2.0.0, status=sent (delivered to maildir)
     Aug 11 19:31:08 mta postfix/qmgr[1022]: 3C8EF868E00: removed
     Aug 11 19:31:08 mta postfix/smtpd[3705]: disconnect from mail-pl1-f179.google.com[209.85.214.179] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1 quit=1 commands=7
    

これにてメールサーバの構築完了です!お疲れ様でした。

📧 9.その他

9章はちょっとしたおまけです。もしよかったら読んでみてください。

📧 9-1.STARTTLSをオプションではなくてコマンドで試す

「STARTTLS使われているというけれど、本当に平文から暗号化通信に切り替えるものなの?」と疑問に思う方もいるのではないのでしょうか?(はい、自分です)
そんな方のために、MTAサーバにてTelnet接続をしたのちにSTARTTLSコマンドを実行する様子を載せておきます。気になる方はご自身で試してみてください!

$ telnet localhost 587
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.example.com ESMTP
EHLO maeba.example.com
250-mail.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
STARTTLS
220 2.0.0 Ready to start TLS
…(以下略)

上記のようにstart TLSしたことが分かりますね!

📧 9-2.エンベロープFromとヘッダFromの違い

実は、私たちが目にしているメールの送信先/送信元とここまでコマンドとして扱ったFROM TORCPT TOは異なるものです。封筒に手紙を入れて相手へ送ることにメール送信を例えると以下の図のようになり、私たちが指定した封筒側のアドレスはユーザーから見えないものだと分かります。

🔗参考リンク:「エンベロープFrom」と「ヘッダFrom」の違いとは?

したがって、Gmail(okuba@gmail.com)にメールを送る時、以下のように意図した名前が表示されるようにメールを作成することができます。

$ openssl s_client -connect localhost:587 -quiet --starttls smtp
…()…
MAIL FROM:maeba@example.com
250 2.1.0 Ok
RCPT TO:okuba@gmail.com
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject:MatlTest To Gmail
From:maeeeeeeeeeeeeeeeeba
To:okuuuuuuuuuuuuuuuuuuba
Watashi ga Honmonoda!!!
.
250 2.0.0 Ok: queued as E26F9868C46
QUIT
221 2.0.0 Bye

上記送信時のGmail側でのメール表示を確認すると、同じMTAサーバから送っているにも関わらず表示が異なるものになりました…。

同じ送信元(MAIL FROMコマンド)だが送信元の名前が異なる①

同じ送信元(MAIL FROMコマンド)だが送信元の名前が異なる②
SPFレコードはエンベロープFrom(MAIL FROMコマンド)で送信元を判別するので、なんと表示がてきとうな今回でもSPFレコードはちゃんとPASSと表示されます。

Thuderbird上に置き換えると「7-2. Thunderbirdの初期設定」の手順1で「前歯すきっ歯」と入れた部分がDATAコマンド内のFromに該当しますね!また、これらのことを試してみると、迷惑メールのタイトルや名前が本物に似ていてもアドレスが本物ではない理由が分かりますね…。

📧 9-3.SPFレコードの弱み

SPFレコードはメール送信に最低限必要なものというレベルなので、他にもよく出てくるDKIMとDMARKについて理解できるとなおよいです!それらについて、個人的に分かりやすかった動画や記事をご共有します。

10. おわりに

初心者がメールサーバを構築しようとすると、メールサーバの設定値以外にも考慮することが多く非常に大変だと感じたので、PostfixやDovecot以外の部分も詳細に記事にしてみました。
少しでも自分以外の初心者の方のお役に立てれば嬉しいです!

Discussion