私が設定した強制制限のため、Postfix経由で電子メールを送信できなくなりました。

私が設定した強制制限のため、Postfix経由で電子メールを送信できなくなりました。

最近まで、私のPostfixサーバーはうまくいっていました。その後、a) スパムを防止し、b) 自分自身に代わってメールを送信できないように、いくつかの制限を実装しました。私のEメールアドレスから誰かにビットコインを送るように頼むEメールを受け取り始めました。

aとbの両方を修正したい。

今私のPostfixサーバーを介して電子メールを送信することはできません。

  Client host rejected: cannot find your reverse hostname, [<my ip here>]

私はノートパソコンを別の場所や国に持ち込み、そこからWi-Fiに接続します。私はいつもメールを送信できるようにしたいです。

これは私の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

ベストアンサー1

短い答え

構成postfixは不必要に複雑です。構成の一部の制限は互いに相殺されたり、制限が過ぎたりするため、sshサーバーに行き、すべての送信メールを手動で送信する必要があります。

この回答では、公開された設定を検索するのではなく、ほとんどの目的に合うように合理的に安全な電子メールシステムを設定するために一般的に必要な事項を簡単に説明します。各コンポーネントの構成方法についての徹底的なチュートリアルではありません。しかし、最後に、私の電子メールサーバーを構成するのに便利で貴重なオンラインリソースのリストがあります。

postfixあなたのコメントには、単一のインストールで複数のドメインを処理するなど、未解決の追加の要件がいくつかあります。合理的に経験豊富な管理者が設定を調整し、必要なマルチドメインコンポーネントを追加できるとします。

最新の小規模電子メールサービスプロバイダの必須要素の概要

セキュリティと評判に関する電子メールヘッダーのグラフィック表示

最新の電子メールシステムは、多くのセキュリティとドメイン関連の評判要素を含むように進化しています。おそらく始める最も簡単な方法は、電子メールヘッダーに含まれているより重要な新しい要素の一部の図を見ることです。

メールヘッダー画像

なりすましの試みや評判の問題からドメインを保護します。

ドメインで発生したように見える電子メールトラフィックの信頼性を確保するには、3つの基本コンポーネントを設定する必要があります。

これらはすべて:

  1. 発信者ポリシーフレームワーク(紫外線遮断指数)
  2. ドメインキーによるメールの識別(DKIM)
  3. ドメインベースのメッセージ認証の報告と一貫性(DMAARC)

これらのそれぞれには、サーバー上で実行されるデーモンと、サーバーに接続してドメインポリシーを自動的に検証し、暗号化署名を検証するために使用されるDNSレコードがあります。

  • 簡単なSPFの説明:

Postfixは、送信者がアウトバウンドEメールポリシーに準拠しているかどうかを評価するSPFデーモンを介してアウトバウンドEメールを配信します。受信メールサーバーはDNSからドメインのSPFレコードを取得し、送信サーバーが電子メールに配置したSPFヘッダーと比較してレコードを確認します。

postfix互換SPFの実装

  • 簡単なDKIMの説明:

Postfixは自動的にメッセージに署名し、電子メールヘッダにハッシュを含むDKIMデーモンを介して送信する電子メールを転送します。受信メールサーバーは、DNSレコードからドメインのDKIM公開鍵を取得し、メッセージの本文ハッシュを確認します。

postfix互換DKIMの実装

  • 簡単なDMARCの説明:

受信メールサーバーは、DNS から DMARC ポリシーレコードを取得し、メッセージを受け入れたり拒否したり、メッセージに対してソフト障害を実行したりします。

postfix互換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=-;

名前付きDNSレコードにmail._domainkey暗号化公開鍵が含まれていることがわかります。このキーと関連履歴は、パッケージがサーバーにインストールされたopendkim-genkeyときにインストールされたプログラムを使用して生成できます。opendkim

鍵の生成は非常に簡単です。

opendkim-genkey -b 2048 -d yourdomain -h sha256 -s mail

このコマンドは、秘密鍵、公開鍵、および正しい形式のDNSレコードを生成します。秘密鍵はopendkim構成にリストされているディレクトリになければなりません。公開鍵と関連する DNS レコードは、ドメインの DNS ゾーンファイルに保存されます。残念ながら、一部のDNSプロバイダにはレコード長制限があります。したがって、DNS プロバイダーが公開鍵の長さに対応できることを確認してください。

SPFおよびDKIMミルターの追加

SPF

マニュアルページからの抜粋policyd-spf

サフィックスの統合

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

Decim

デーモンopendkimは、標準のUNIXソケットで構成されているか、inetdサービスポートで実行できるUNIXソケットで実行されます。私のDebianインストールでは、この設定はにあります/etc/default/opendkim。を実行した後、milterをの設定opendkimに追加する必要があります。postfix/etc/postfix/main.cf

以下は、稼働中のサーバーの例です。

# 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(Evolution、Sylpheed、Muttなど)からユーザー名とパスワードを安全に送信するには、TLSを有効にしてDovecotで適切に設定する必要があります。

参考までに以下を参照してください。DovecotのTLS設定文書

postfixを使用したサーバー間またはミドルウェア接続は、同じTLS証明書で暗号化できますが、必須ではありません。しかし、小規模な電子メールサーバーでは、Postfix Connectの「ミドルウェア」は同じハードウェアにあるため、必ずしも暗号化は必要ありません。

メールサーバーとMUAインターフェイス(POP3、IMAPなど)のLetsEncrypt TLS証明書を取得します。

これ暗号化しようこのプロジェクトは、ドメイン検証TLS証明書の取得を簡素化するのに非常に役立ちます。ドメインにすでに証明書があると仮定すると、この--expandオプションを使用してメールサーバーのサブドメインを証明書に追加できます。

  1. postfixとdovecotサービスを停止します。
  2. Webサーバーが稼働している場合は、サーバーを停止します。
  3. 現在の証明書に含まれており、実行中のすべてのサービスを停止します。
  4. 証明書の拡張

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設定に証明書パスを追加します。

  1. すべてのサービスを再起動し、設定が有効であることを確認してください。

SMTP TLS接続は、サーバーが別のサーバーに接続することです。ただし、Dovecot TLS 接続は通常、Web メールではなくクライアントから電子メールを送信するために人々が接続することです。

SMTPサーバー間TLS互換性の設定

一部のメールサーバーは、他のサーバーから受信したメールに対してまだTLS暗号化接続を使用していません。この場合、厳密な TLS 施行によりメールはそのサーバーとドメインに転送されません。ただし、多くの大規模な電子メールプロバイダーは、接続がTLSで保護されていない場合、受信した電子メールを疑わしいとマークします。したがって、最適な互換性を維持するには、アプリケーションに次の設定を含めます。/etc/postfix/main.cf

smtpd_tls_security_level = may

ほとんどの電子メールプロバイダは、CA承認証明書を使用するためにこれらのサーバー間接続を必要とせず、証明書がCA承認を受けても通常は検証されないことに注意することも重要です。

ただし、Dovecotに含まれるTLS証明書はCAによって承認されなければなりません。 Dovecotの自己署名証明書は、ほとんどのMUA(例sylpheed:。evolutionthunderbird

合理的な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%が正しいリバースドメイン履歴を持たない電子メールサーバーから送信されます。

ヘリコプター検査

スパマーは、ドメイン名、IPアドレス、またはローカルホストを送信して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アドレスです。

このデータベースの例では、実際のサーバーログで次のような結果が生成されます。

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通程度のスパムメールが届きましたが、そのうち何百通も拒否されました。

リソース

  1. DMARC/SPF ポリシー評価者
  2. DKIM公開鍵評価者
  3. MxToolboxウェブサイト
  4. 電子メールセキュリティグレーダー

おすすめ記事