制限が適用されたため、自分のPostfix経由でメールを送信できなくなりました
最近まで、私のサーバーはPostfixでうまく機能していました。次に、a）スパムとの戦いb）自分の名前に代わって自分へのメール送信を無効にするいくつかの制限を適用しました-自分のメールアドレスから誰かにビットコインを送信するように要求するメールを受信し始めました。
Aとbの両方を修正したい。
そして今、私は自分のpostfixサーバーを介してメールを送信することができません。
Client Host rejected: cannot find your reverse hostname, [<my ip here>]
ラプトットをさまざまな場所や国に運び、そこからWiFiに接続していることに注意してください。また、常にメールを送信できるようにしたいのです。
これがPostfixの私の設定の一部です。アカウントとドメインのデータベースには、Postgresqlを使用します。
smtpd_helo_required = yes
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_reverse_client_hostname,
reject_unknown_client_hostname,
reject_unauth_pipelining
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_helo_hostname,
### reject_non_fqdn_helo_hostname,
reject_unauth_pipelining
smtpd_sender_restrictions =
permit_mynetworks,
reject_sender_login_mismatch,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unauth_pipelining
smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unauth_destination
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unauth_pipelining
smtpd_data_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_multi_recipient_bounce,
reject_unauth_pipelining
# deliver mail for virtual users to Dovecot's LMTP socket
virtual_transport = lmtp:unix:private/dovecot-lmtp
# query to find which domains we accept mail for
virtual_mailbox_domains = pgsql:/etc/postfix/virtual_mailbox_domains.cf
# query to find which email addresses we accept mail for
virtual_mailbox_maps = pgsql:/etc/postfix/virtual_mailbox_maps.cf
# query to find a user's email aliases
virtual_alias_maps = pgsql:/etc/postfix/virtual_alias_maps.cf
virtual_alias_domains =
alias_database =
alias_maps =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
inet_interfaces = all
短い答え
postfix構成は不必要に複雑です。構成に課せられた制限のいくつかは、互いに打ち消し合っているか、非常に制限されているため、サーバーにsshを設定して、各送信メールを手動で送信する必要がある可能性があります。
この回答では、投稿された構成を経由するのではなく、ほとんどの目的でかなり安全な電子メールシステムを構成するために一般的に必要なものの概要を示します。これは、各コンポーネントの構成方法に関する完全なチュートリアルを目的としたものではありません。ただし、最後にオンラインリソースのリストがあり、自分の電子メールサーバーの構成にかなり役立ち、価値があることがわかりました。
単一のpostfixインストールを使用して複数のドメインを処理するなど、対処されないコメントからの追加の要件がいくつかあります。適度に熟練した管理者は、設定を微調整し、必要なマルチドメイン構成要素を追加できると想定されています。
最新の小規模メールサービスプロバイダーの要素の概要
セキュリティとレピュテーションに関連する電子メールヘッダーのグラフィカルビュー
最新の電子メールシステムは、多くのセキュリティおよびドメイン関連のレピュテーション要素を含むように進化してきました。おそらく、始める最も簡単な方法は、電子メールのヘッダーに含まれているいくつかのより重要な新しい要素の図を見ることです。
なりすましの試みや評判の問題からドメインを保護する
ドメインから発信されているように見える電子メールトラフィックの信頼性を確保するために構成する必要のある3つの重要なコンポーネントがあります。
これらは：
- Sender Policy Framework （SPF）
- ドメインキー識別メール （DKIM）
- ドメインベースのメッセージ認証のレポートと適合性 （DMARC）
これらはそれぞれ、サーバー上で実行されているデーモンと、ドメインポリシーのチェックと暗号化署名の検証を自動化するために、サーバーを接続するためのDNSレコードを備えています。
- 簡単なSPFの説明：
Postfixは、送信者が送信メールポリシーに一致するかどうかを評価するSPFデーモンを介して送信メールを渡します。受信メールサーバーはDNSからドメインのSPFレコードを取得し、送信サーバーがメールに配置したSPFヘッダーとレコードを照合します。
- 簡単なDKIMの説明：
Postfixは送信メールをDKIMデーモンに渡します。DKIMデーモンはメッセージに自動的に署名し、メールヘッダーにメッセージのハッシュを含めます。受信メールサーバーは、DNSレコードからドメインのDKIM公開鍵を取得し、メッセージの本文ハッシュを確認します。
- 簡単なDMARCの説明：
受信メールサーバーは、DNSからDMARCポリシーレコードを取得し、メッセージを受け入れるか拒否するか、メッセージのソフトフェイルを実行します。
ドメインがメールを送信していない場合でも、「拒否」DMARCポリシーレコードを入力することはベストセキュリティプラクティスと見なされます。
SPF、DKIM、DMARCのDNSエントリの例
MX 10 mail.domain.tld.
TXT "v=spf1 a:mail.domain.tld -all"
mail._domainkey IN TXT ( "v=DKIM1; h=sha256; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0w7N0fWtTndtlR+zOTbHyZOlvFiM73gyjjbHDN1OhhcPCbhRUqTsA7A8uXHGHao6nZ5qejlVtn6NfZwbn7rdhJ0MTjlgTnTsVa8E9rgS6dFo0bEIzeFecDr/4XOF9wpNjhHlnHm4wllkPheFnAWpZQiElZeYDN5Md47W1onwZ3DwcYJNX/3/GtfVZ0PrjisC4P0qeu+Z8jIgZc"
"MLvBm8gj2pX3V6ntJY9QY09fWSVskvC6BQhi6ESOrqbM63f8ZJ4N/9ixPAMiD6k/lyGCokqc6sMuP6EC7z5McEOBbAVEuNy3idKi1sjwQH8WZHrvlSBlzx1wwmpFC1gqWcdTiEGwIDAQAB" ) ; ----- DKIM key mail for domain
_dmarc IN TXT v=DMARC1;p=reject;sp=reject;fo=0:d;adkim=s;aspf=s;rua=mailto:[email protected];ruf=mailto:[email protected];
_domainkey IN TXT o=-;
mail._domainkeyという名前のDNSレコードに暗号化された公開鍵が含まれていることに気付くでしょう。このキーと関連レコードは、サーバーにopendkimパッケージがインストールされたときにインストールされたopendkim-genkeyプログラムを使用して生成できます。
鍵の生成はかなり単純です。
opendkim-genkey -b 2048 -d yourdomain -h sha256 -s mail
このコマンドは、秘密鍵、公開鍵、および正しくフォーマットされたDNSレコードを生成します。秘密鍵は、opendkim構成にリストされているディレクトリーに配置する必要があります。公開鍵とそれに関連するDNSレコードは、ドメインのDNSゾーンファイルに配置されます。残念ながら、一部のDNSプロバイダーにはレコードの長さ制限があります。したがって、DNSプロバイダーが公開鍵の長さに対応できることを確認してください。
SPFおよびDKIMミルターの追加
[〜＃〜] spf [〜＃〜]
policyd-spfのマニュアルページからの抜粋：
POSTFIX統合
1. Add the following to /etc/postfix/master.cf:
policyd-spf unix - n n - 0 spawn
user=policyd-spf argv=/usr/bin/policyd-spf
2. Configure the Postfix policy service in /etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_policy_service unix:private/policyd-spf
...
policyd-spf_time_limit = 3600
[〜＃〜] dkim [〜＃〜]
opendkimデーモンは、標準のUNIXソケットとして構成可能なUNIXソケットで実行されるか、inetdサービスポートで実行されます。私のDebianインストールでは、この構成は/etc/default/opendkimにあります。 opendkimが実行されたら、ミルターを/etc/postfix/main.cfのpostfix構成に追加する必要があります。
稼働中のサーバーの例を次に示します。
# DKIM
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
[〜＃〜] dmarc [〜＃〜]
小規模または個人の電子メールサーバーの場合、DMARCは単にDNSレコードに制限できます。 DMARCチェックデーモンを使用すると、送信ドメインのポリシーに従って受信メールを拒否したり、要求されたレポートを送信ドメインに送信したりできます。報告は「行儀の良い隣人」であると見なされます。ただし、構成のオーバーヘッドが非常に高いため、通常、小規模または個人のシステムでは有効にしません。
ただし、DMARC DNSレコードは、ドメインレピュテーションを維持するために非常に重要です。このレコードは、最近のすべての大規模な電子メールプロバイダーによって、ドメインから送信されたように見えるメールを受け入れるか拒否するために使用されます。したがって、DMARCレコードがないと、ドメインから送信されたように見えるすべての受信メールが、ドメインのレピュテーションスコアにカウントされます。したがって、メールの送信をまったく期待しないドメインは、スパマーによって送信されたなりすましメッセージによるレピュテーションの問題を回避するために、「拒否」DMARCレコードを公開する必要があります。
電子メールサーバーとクライアントのTLS接続
構成情報は、DovecotとPostfixを実行していることを示しています。
Dovecotはサーバー上のPostfixに接続します。多くの小規模なインストールでは、サーバー接続は、Unixソケットを介して同じ物理/論理ハードウェアで実行されます。
したがって、メールユーザーエージェント（MUA）接続は、実際のメールサーバーではなく、ミドルウェアによって処理されます。あなたの場合、それはDovecotです。
MUAからユーザー名とパスワードを安全に送信するには、DovecotでTLSを有効にして適切に設定する必要があります（例：Evolution、Sylpheed、Muttなど）。
参考までに、 DovecotのTLSセットアップドキュメント を参照してください。
「サーバー間」または「ミドルウェア」が後置接続を同じTLS証明書で暗号化することは可能ですが、必須ではありません。ただし、小さな電子メールサーバーの場合、postfix接続への「ミドルウェア」は同じハードウェア上にあるため、必ずしも暗号化する必要はありません。
メールサーバーとMUAインターフェイス（POP3、IMAPなど）のLetsEncrypt TLS証明書を取得する
LetsEncryptプロジェクトは、ドメイン検証済みTLS証明書の取得を簡素化する非常に優れた仕事をしました。ドメインにすでに証明書がある場合は、--expandオプションを使用してメールサーバーのサブドメインを証明書に追加できます。
- Postfixおよびdovecotサービスを停止します。
- Webサーバーが実行中の場合は停止します。
- 現在証明書に含まれている実行中のサービスを停止します。
- 証明書を展開する
certbot certonly --expand -d domain.tld,www.domain.tld,mail.domain.tld
次に、証明書パスをmain.cf構成に追加します。
smtpd_tls_key_file = /etc/letsencrypt/live/domain.tld/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/domain.tld/fullchain.pem
また、上記のDovecotのドキュメントに従って、Dovecot構成に証明書パスを追加します。
- すべてのサービスを再起動し、構成が機能することを確認します。
SMTP TLS接続は、サーバーが他のサーバーと行う接続であることに注意してください。一方、Dovecot TLS接続は、通常、ウェブメール以外のクライアントからメールを送信するために誰かが接続するものです。
SMTPサーバー間TLS互換性設定
一部のメールサーバーは、他のサーバーから受信したメールにTLS暗号化接続をまだ利用していません。このような場合、TLSを厳密に適用すると、それらのサーバーおよびドメインにメールが配信されなくなります。ただし、多くの大規模な電子メールプロバイダーは、接続がTLSで保護されていない場合、受信電子メールを疑わしいものとしてマークします。したがって、最高の互換性を維持するには、/etc/postfix/main.cfに次の設定を含めます
smtpd_tls_security_level = may
ほとんどの電子メールプロバイダーは、CA承認済み証明書を使用するためにこのサーバー間接続を必要とせず、証明書がCA承認済みであっても検証チェックは通常実行されないことに注意することも重要です。
ただし、Dovecotに含まれているTLS証明書はCAで承認されている必要があります。 Dovecotの自己署名証明書は、sylpheed、evolution、ThunderbirdなどのほとんどのMUAを使用すると警告が表示されます。
合理的なSMTPクライアントの制限
私の経験では、スパムの99％は、SPF、DKIMチェック、およびRBLチェックを介して拒否できます。
これが私の「標準」クライアント制限の一部です。制限は順番に処理されることに注意してください。以下の順序は、私の経験では非常にうまく機能しています。
smtpd_client_restrictions = permit_mynetworks
permit_sasl_authenticated
check_helo_access hash:/etc/postfix/helo_access
check_client_access hash:/etc/postfix/client_checks
reject_unauth_destination
check_policy_service unix:private/policy-spf
reject_rbl_client cbl.abuseat.org
reject_rbl_client pbl.spamhaus.org
reject_rbl_client sbl.spamhaus.org
reject_rbl_client bl.blocklist.de
reject_unknown_client
SMTPDクライアント制限互換性設定
最も例外が多い制限は、reject_unknown_client設定です。多くのオンラインサービスは、リバースドメインを正しく構成していないか、適切にマッピングされている場合とされていない場合がある一連の送信ドメインを利用しています。したがって、構成が不十分な電子メールプロバイダーとの互換性を最大限に高めるには、その制限を削除します。
ただし、スパムのほぼ100％は、適切な逆ドメインレコードなしで電子メールサーバーから送信されます。
HELOチェック
スパマーがドメインの名前やIPアドレス、またはlocalhostを送信してHELOを偽装することはよくあります。これらのなりすましの試みは、上記のようにcheck_helo_accessオプションを使用してすぐに拒否できます。 HELOテキストデータベースは、ドメイン名、IPアドレス、またはIPアドレスの範囲で構成され、その後にアクションと返信メッセージが続きます。
かなり単純なHELOチェックは次のとおりです。
# helo access
# check_helo_access hash:/etc/postfix/helo_access
localhost REJECT Only I am me
127.0.0.1 REJECT Only I am me
example.com REJECT Only I am me
dns.Host.ip.addr REJECT Only I am me
「example.com」はドメインであり、「dns.Host.ip.addr」はサーバーのDNSにリストされたIPアドレスです。
このデータベースの例では、実際の1つのサーバーログから次のような結果になります。
Oct 30 06:32:49 <domain> postfix/smtpd[22915]: NOQUEUE: reject: RCPT from xxx-161-xxx-132.dynamic-ip.xxxx.net[xxx.161.xxx.132]: 554 5.7.1 <xxx.xxx.xxx.xxx>: Helo command rejected: Only I am me; from=<[email protected]> to=<[email protected]> proto=SMTP helo=<xxx.xxx.xxx.xxx>
潜在的なスパマー/スプーファーは、「私だけが私です」というメッセージを受け取ります。メッセージが何であるかは問題ではありませんが、少なくともスパマー/スプーファーはあなたが知っていることを知っています。
以下を使用して、必ずpostfixデータベースを生成してください。
postmap helo_access
client_checkホワイトリストを介して制限に例外を追加する
個々のクライアントのチェックは次のようになります。
ip.addr.hack.attmpt REJECT
misconfig.server.but.good OK
以下を使用して、必ずpostfixデータベースを生成してください。
postmap client_checks
そしてそれはそれについてです。毎月約3通のスパムメールが届き、何百通ものスパムが拒否されました。
資源
たとえば、ポート587の送信インターフェイス（MSA-メール送信エージェント）に異なる制限を使用します（master.cfの抜粋）。
submission inet n - - - - smtpd
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_sender_restrictions=reject_authenticated_sender_login_mismatch
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
STARTTLSを強制し、認証後にのみ送信を有効にします。これが最も簡単な方法です。コメントで提案されているVPNなどを使用して、この方法でIP /範囲をホワイトリストに登録することもできます。
MSA（ポート587）とMTA（メールトランスポートエージェント、ポート25、465）に異なるポートを使用することをお勧めします。これは、両方に異なる設定が必要になるためです。
これは最小の例です。必要に応じて拡張してください。