コンテンツにスキップ 
その方法をお見せしよう。 メールサーバー TLS SMTP接続が一貫して保護されるように、Postfixで強力な暗号スイートを選択します。TLS 1.2/1.3、DANE、MTA-STSおよび最新のキーペアのための試行錯誤されたパラメータに基づき、設定、テスト、チューニングを順を追って説明します。 メールセキュリティ グリップをきれいに握る。.
中心点
- ポストフィックス 安全に設定：TLSの有効化、プロトコルの制限、ロギングの設定。.
- 暗号 を優先する：ECDHE + GCM/CHACHA20、PFSの実施、レガシーデータのブロック。.
- 証明書 クリーンに保つ：RSA+ECDSA、完全なチェーン、強力なカーブ。.
- DANE/MTA-STS 利用する：ガイドラインのアンカリングと格下げリスクの軽減。.
- テスト 監視： OpenSSL、TLSスキャナ、MTAログを定期的にチェックする。.
TLS経由のSMTP：何が本当に安全か
でSMTPを保護する。 STARTTLS, 電子メールの転送がプレーンテキストで行われないようにする。オポチュニスティックTLS smtpd_tls_security_level = may 着信接続では、リモート・ステーションが暗号化を提供すると同時に、暗号化が使用されるようにする。送出には smtp_tls_security_level = dane DNSSECがサポートするポリシー・チェックにより、ダウングレード攻撃がより困難になります。TLSがなければ、メールは転送中に読まれたり操作されたりする可能性があり、フォームや注文、口座データにとっては特に危険です。終始TLSが有効なため、盗聴やMITMのリスクを大幅に減らすことができ、大手のプロバイダーが安全な接続を好意的に評価するため、配信率も向上しています。.
Postfixにおける鍵、証明書、プロトコル
私は2つの証明書を用意している。 アールエスエー-証明書とECDSA証明書を使って、新旧のMTAが最適に接続されるようにした。Postfixのパスは次のように明確に設定した。 smtpd_tls_cert_file RSAと smtpd_tls_eccert_file ECDSAの場合、それぞれが一致する鍵を持っている。クリーンな認証のために、私は完全なチェーン、ホストに正確に一致するCN/SAN、そして以下のようなカーブに注意を払う。 secp384r1 をECDSAキーに使用する。私は、強制的なダウングレードを防ぐために、古いプロトコル、つまりSSLv2やSSLv3を厳格に無効化している。証明書の種類を検討される場合は、以下のサイトをご覧ください。 DV、OVまたはEV, 適切な信頼度を選択できるように。.
暗号の選択：TLS 1.2/1.3の優先順位
の暗号スイートを優先する。 ピーエフエス, すなわち、DHEの前にECDHEを使用し、GCMまたはCHACHA20-POLY1305を使用する。TLS 1.3では、スタックは多くのレガシーな問題から解放してくれるが、TLS 1.2ではまだ明確なリストが必要だ。TLS1.2ではまだ明確なリストが必要です。 アールシーフォー, 私は3DES、CAMELLIA、aNULL、eNULLを削除している。Postfixでは smtpd_tls_ciphers = high と制限的な tls_high_cipherlist, 時代遅れのアルゴリズムがすり抜けないように。さらに深く掘り下げると 暗号スイートガイド バラストのないわかりやすいカテゴリー分け。.
| TLSバージョン | お気に入りの暗号スイート | ステータス | ヒント |
|---|---|---|---|
| TLS 1.3 | TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 | アクティブ | セレクションはしっかりとプロトコルに組み込まれ、レガシーの問題はなくなった。. |
| TLS 1.2 | ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305 | アクティブ | PFSを優先し、GCM/CHACHAを好む。. |
| 廃止 | RC4、3DES、CAMELLIA、AES128-SHA、aNULL/eNULL | 鍵付き | セキュリティ上の理由から完全に無効化する。. |
Postfix: main.cfの具体的なパラメータ
私は、MTAがインバウンドとアウトバウンドの両方でセキュアに話すように、明確なコンフィギュレーションを設定しました。エフェメラルECDHには smtpd_tls_eecdh_grade そして、CRIMEのような攻撃を避けるために圧縮を解除している。4096ビットの強力なDHファイルは、弱いDHE交渉を防ぐ。プロトコルに厳しい制限をかけ、TLS 1.3のような高い暗号品質を強制している。最初のうちは、適度なログレベルで、ジャーナルを溢れさせることなくハンドシェイクをチェックできるようにしている。.
# アクティベーションとポリシー
smtpd_tls_security_level = may
smtp_tls_security_level = dane
#証明書（パスの例）
smtpd_tls_cert_file = /etc/ssl/certs/mail.example.de.cer
smtpd_tls_key_file = /etc/ssl/private/mail.example.de.key
smtpd_tls_eccert_file = /etc/ssl/certs/mail.example.de_ecc.cer
smtpd_tls_eckey_file = /etc/ssl/private/mail.example.de_ecc.key
#プロトコルと暗号
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = high
tls_high_cipherlist = !aNULL:!eNULL:!RC4:!3DES:!CAMELLIA:HIGH:@STRENGTH
tls_ssl_options = NO_COMPRESSION
smtpd_tls_eecdh_grade = ultra
# DHパラメータ
smtpd_tls_dh1024_param_file = /etc/postfix/dh_4096.pem
# DNSSEC/DANE (利用可能な場合)
smtp_dns_support_level = dnssec
#ログ
smtpd_tls_logle レベル = 1
私は証明書チェーンを完全な状態に保ち、次のような正しい権利に注意を払う。 プライベート キーファイルを再読み込みし、再読み込み後のログをチェックする。レガシー・パートナーのためにTLS 1.2が必要な場合は、GCM/CHACHAに厳密にこだわり、それ以外はすべてブロックする。TLS 1.3の場合は、スタックの標準に頼り、メンテナンスが難しくなるような特別なパスは避ける。OCSPステープリングは、アップストリームプロキシが提供する場合にのみSMTPで役割を果たすので、対応するセットアップの場合にのみチェックする。変更のたびにOpenSSLで検証を行い、副作用を早期に認識し 電子メールの暗号化 一貫している。.
DANE、MTA-STS、SPF、DKIM、DMARCによるトランスポート認証
私はTLSを DANE, DNSSECの下で署名されたTLSAレコードを公開することによって。さらに、MTA-STSを設定して、私のホストがTLSを要求していることと、どのMXに従うべきかをリモートのピアに知らせます。IDバインディングのために、私は送信メールに ディーケーアイエム とSPFルールによるセキュアなドメイン配送を提供する。最後に、DMARCは受信者がどのように逸脱に対処すべきかを定義し、なりすましをより難しくしている。これらのコンポーネントは連携して機能する：TLSはトランスポートを保護し、認証は送信者を強化し、配信率を顕著に向上させる。.
パフォーマンスがボトルネックになっている場合は、セッション再開、ハードウェア機能、ハンドシェイクそのものを最適化する。実践的なトリックは TLSハンドシェイクの高速化, 接続を確立する際の待ち時間を短縮する。重要：暗号の選択と再開のバランスを保つ。弱い妥協はセキュリティの面で報われないからだ。迅速なTLSネゴシエーションは、特にメール量が多い場合に大きな節約をもたらします。この方法 スループット と安全保障のバランスが取れている。.
テスト、モニタリング、監査
でローカルに握手をチェックする。 オープンスル を実行し、プロトコルのバージョン、暗号、証明書チェーンをチェックする。コマンド openssl s_client -connect mail.example.de:25 -starttls smtp は、リモートサーバーが何をネゴシエートしているかをライブで表示してくれる。コンフィギュレーションを変更した後は ポストフィックスチェック を具体的に見てみよう。 smtpd_tls_logle レベル, を使用してエラーパターンを分離する。外部のTLSスキャナは、特に証明書の変更後に、公開された可視性を分類するのに役立つ。定期的な監査サイクルは、例えばライブラリの変更が暗号の優先順位に影響した場合など、忍び寄る悪化から保護する。.
頻繁な設定ミスと迅速な修正
のような時代遅れの暗号をよく目にする。 AES128-SHA, はまだ有効であり、PFS を防ぐ。厳密な暗号文字列とLOW/MD5/RC4/3DESの明確なブロックがここで役立つ。2つ目のパターン：中間証明書が見つからないため、リモートステーションがチェーンを検証できない。バンドルファイルを追加して、再度テストする。Synologyのようなアプライアンスでは、TLSプロファイルを最新に設定し、SMTPサーバーが最新を話すようにレガシーオプションを削除する。Microsoft Exchangeの場合、特にTLS 1.2/1.3ポリシー、コネクタごとの証明書割り当て、ホスト設定の暗号オーバーライドをチェックし、SMTPサーバーがモダンを話すようにします。 握手-セレクションは正しい。.
プレビューTLS 1.3、0-RTT、ポスト量子
私はTLS 1.3の方が好きだ。ハンドシェイクが短くなり、古いオプションが省略されて攻撃対象が減るからだ。ハンドシェイクの 暗号 リプレイ攻撃は不必要なリスクをもたらすので、私はSMTPコンテキストでは0-RTTを使用しない。将来的には、標準化とサポートが成熟し次第、メール環境にも導入される可能性のあるハイブリッドポストクォンタムプロシージャに注目している。新しい手続きを後で混乱なく統合できるように、ポリシーと監視を設定することが重要であることに変わりはない。.
パフォーマンスと納品率が一目でわかる
を測定する。 レイテンシー のTLSハンドシェイクと、再利用を可能にするキャッシュの最適化。セッション再開(チケット/ID)は、計算負荷を軽減し、MTA間の繰り返し接続を高速化する。証明書の失効については、利用可能であれば、アップストリームプロキシでのスタッカブル情報に依存し、追加のアクセスを節約する。大口の受信者は安全なトランスポートを好意的に評価するため、配信率が向上するが、安全でないパスはスパムや拒絶のリスクを増大させる。明確なTLSポリシー、確実なDNSエントリー、クリーンな署名チェーンにより、私は以下のような信頼できる基盤を構築している。 配達可能性.
私のセットアップ・スケジュール
まず信頼できるCAから証明書を取得し、ECDSAとRSAを生成して、その両方をホストにきれいに保存します。それから メインCF を TLS パラメーターで設定し、強力な暗号を設定し、古いプロトコルを無効にする。4096ビットの新しいDHファイルを追加し、リロードして最初のOpenSSLチェックを行います。その後、DANEをセットアップし、MTA-STSを追加し、SPF/DKIM/DMARCの有効性を検証する。最後に、外部ターゲットに対してテストを実行し、運用中のログをチェックし、定期的な監査をスケジュールして 構成 は長期的に安定している。.
欠落モジュール：Submission、SMTPS、SNI
ポート25だけでなく、サブミッション（587）やオプションでSMTPS（465）もセキュアにしています。送信に関しては、暗号化と認証を強制し、ユーザーのパスワードが平文で送信されることがないようにしています。また master.cf 私はサービスを有効化し、特定のオーバーライドを設定する：
STARTTLSと認証義務を持つ#サブミッション(ポート587)
サブミッション inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
# SMTPS(ポート465)をラッパーモードにする(必要な場合)
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
1つのホストで複数のメール・ドメインに独自の証明書を使用する場合は、次のようにします。 エスエヌアイ. .SNIマップを使用して、各ターゲットホストに適切な証明書パスを割り当て、MUAクライアントにも正しい証明書が表示されるようにしています。このようにして、一貫したTLS IDでクライアントを分離している。.
ドメイン単位のポリシー：きめ細かな制御
グローバル・ポリシーに加え、私は次のような管理も行っている。 smtp_tls_policy_maps 受信者ドメインごとの例外と厳格化。これにより、レガシーパートナーを徐々に移行させたり、機密性の高いターゲットに特に厳しい要件を課すことができる。.
# main.cf
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# /etc/postfix/tls_policy (エントリ例)
example.org dane-only
legacy.example.net may
secure.example.com secure
デーンオンリー は、CAに依存することなくDANE保護を実施する、, セキュア は有効なCAチェーンを要求し、プレーンテキストの配信を拒否する、, かもしれない ご都合主義のまま。変更後、私は ポストマップ を実行し、Postfixをリロードする。.
DANEとMTA-STS：具体的な実装
のために DANE DNSSECでTLSAレコードを公開している。私はDANE-EE (3 1 1)を使用することを好むが、それは公開鍵へのピン留めを可能にし、同じ鍵での証明書の変更を容易にするからである。TLSAレコードの例 _25._tcp.mail.example.de こんな感じだ：
_25._tcp.mail.example.de.IN TLSA 3 1 1 .
ECDSAまたはRSA証明書からハッシュを生成し、有効期限が切れる前にローテーションするようにしています。DNSゾーンが署名され、委任のチェーンが隙間なく検証されていることが重要です。.
のために MTA-STS ポリシーファイルをHTTPSでホストし、TXT DNSエントリーを追加する。こうすることで、リモートのピアがTLSを話し、定義されたMXでのみ受け入れられるように指定します。最小限のポリシーファイル
バージョン: STSv1
モード：強制
mx: mail.example.de
最大年齢: 604800
TXTエントリーは、DNSの _mta-sts.example.de 現在のバージョンで。オプションで TLS-RPT TXT経由 _smtp._tls.example.de ポリシー違反に関するレポートを受け取ることができます。この遠隔測定は、障害、格下げ、欠陥のある証明書を早い段階で認識するのに役立つ。.
プロトコルの厳格化、暗号の指定
プロトコルの制限を厳しくし、サーバーの優先順位を強制する。TLS 1.0/1.1は現在では不要である。 TLS 1.2と1.3は深く、かつ発信ベースでのみ許可している。 TLS 1.2については、古い暗号の混合ストックを除外するために、明示的なポジティブリストを定義している：
# 追加のハードニング (main.cf)
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# 明示的な TLS 1.2 暗号リスト（PFS + AEAD のみ）
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:!MD5:!RC4:!3DES:!CAMELLIA
# サーバーの優先順位を使用する
tls_preempt_cipherlist = yes
ECDHEが優先され、DHEはフォールバックに過ぎない。TLS 1.3では、DHファイルは役割を果たしませんが、まれにDHEを使用するときには便利です。.
セッションの再開とキャッシュ
スピードアップのために、クライアントとサーバーのセッションキャッシュを有効にして、再接続をより有利にしています。CPUの負荷と待ち時間は、特にメールのスループットが高い場合に顕著に減少します：
# セッションキャッシュ (main.cf)
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_connection_reuse = yes
私はログでヒット率を監視し、短すぎるものがないことを確認している。 チケット有効期限 をTLSライブラリに追加することで、再開を遅くすることができる。重要：再開はポリシーを弱めるものであってはならない。.
認定会社：ローテーションとチェーンメンテナンス
私はMTAの更新と再ロードを自動化し、期限切れの証明書が運用されないようにしている。更新のたびに、リーフ証明書と中間証明書が完全にバンドルされているかどうかをチェックする。ECDSA/RSAの二重運用の場合は、大量の変更によってクライアントに問題が発生する前に、両方のペアがローテーションしていることを確認する。MUAはMTAとは異なるエラーパターンを示す可能性があるため、SNIパスとサブミッションを別々にテストしている。.
ロギングと診断の強化
私は問題が発生したときに一時的にログの深さを増やし、クロスチェックのためにオンボードツールを使用する：
#を対象としたロギング (main.cf)
smtp_tls_logle レベル = 1
smtp_tls_note_starttls_offer = yes
と一緒に posttls-finger target.example.com リモートMTAがどのポリシーを期待し、どの暗号/プロトコルがネゴシエートされているかをチェックする。私は postconf -n | grep tls, 明示的に設定されたTLSパラメーターだけを見ることができる。この方法なら、デフォルトからの逸脱をより迅速に見つけることができる。ログでは、次のような用語を検索している。 共有暗号なし, 証明書の検証に失敗しました 或いは プロトコルバージョン, これは、暗号の不一致、チェーンの問題、プロトコルの制限が厳しすぎたり緩すぎたりすることを直接示している。.
セキュリティを犠牲にすることなく互換性を管理
私は意識的にトランジションを計画している。 かもしれない, レガシーサーバーからのメールがすべて失われるのを避けるため、プレーンテキストの配信を記録しています。送信は厳密なまま（DANE/MTA-STS/secure）にしています。 smtp_tls_policy_maps 個々のケースについてもし個々のパートナーがAES-GCMでTLS 1.2しか管理できないのであれば、これは許容範囲です。私はこれ以下のものはすべて、限られたランタイムで合意された例外によって管理し、文書化して移行計画に含めています。これにより、業務を妨げることなく、全体のレベルを高く保つことができる。.
システムのTLSデフォルト一覧
PostfixはシステムのTLSライブラリを使用していることに注意してください。OpenSSL/LibreSSLのアップデートにより、暗号の優先順位やTLS 1.3の動作が変更される可能性があります。そのため、システムのアップデート後は、ランダムにハンドシェイクをチェックし ポストコンフ -n を目標値で設定した。Aセット 互換性レベル は安定したデフォルトを維持するのに役立ちますが、私は盲目的にこれに頼らず、main.cf/master.cfで明示的に逸脱を文書化しています。.
管理者向け概要
PFSによる強力な暗号、クリーンな証明書、そして明確なポリシーは、次のような場合に不可欠であることを強調したい。 エスエムティーピー 極めて重要だ。TLS 1.3はレガシーな問題から解放し、TLS 1.2は規律ある暗号リストを要求する。DANEとMTA-STSはトランスポート・パスを強固にし、SPF/DKIM/DMARCはアイデンティティとレポートを安全にする。定期的なテストとログ分析によって、変更が望ましくない副作用をもたらすかどうかが早期にわかります。このガイドを読めば、不必要な変更をすることなく、安全で、性能が高く、将来性のあるメールサーバーをセットアップすることができます。 リスク.
