
問題は、MS Outlook 2007 が何らかの奇妙な理由で特定のドメインに対してのみ SMTP AUTH を送信しないことにあるようです。
私は自分のドメインと数十のクライアント ドメイン用に iRedMail サーバー (標準の Debian 7/wheezy、postfix 2.9.6-2 を使用) を実行しています。問題は、クライアントが自分自身に (自分のメールだけでなくドメイン全体に) メールを送信できないことです。メールは拒否されますが、reject_non_fqdn_helo_hostname
クライアントは SMTP AUTH を使用しており、正しく設定されているため、FQDN チェックはバイパスされるはずです。MUA が私と同僚のメール アドレスに対してのみ SMTP AUTH を使用していないように見えます。
誰かこれを見たことがありますか? この問題を回避するにはどうすればいいですか? ご意見をお待ちしております!
MUA に接続されているのでしょうか? 彼女は Outlook (Express ではない) を使用していますか?
さまざまな状況を示すログの次の抜粋をご覧ください。すべて同じ構成/同じ MUA/IP でキャッチされました。
1) これは問題ありません: クライアントはSMTP AUTHを使用してサードパーティのサーバーにメールを送信します
5月28日 13:02:13 email2 postfix/smtpd[1191]: <censored>から接続 5月28日 13:02:13 email2 postfix/smtpd[1191]: 28A5D35E61DC: client=<censored>、sasl_method=LOGIN、sasl_username=<[メールアドレス]> 5月28日 13:02:26 email2 postfix/cleanup[1435]: 28A5D35E61DC: message-id=<006c01ce5b92$d33805e0$79a811a0$@cz> 5月28日 13:02:44 email2 postfix/qmgr[376]: 28A5D35E61DC: from=<[メールアドレス]>、サイズ=4392922、nrcpt=7 (キューがアクティブ) 5月28日 13:02:44 email2 postfix/smtp[1580]: 28A5D35E61DC: to=<[メールアドレス]>、リレー=127.0.0.1[127.0.0.1]:10024、遅延=32、遅延=31/0/0/0.88、dsn=2.0.0、ステータス=送信済み (MTA(smtp:[127.0.0.1]:10025 からの 250 2.0.0): 250 2.0.0 Ok: B061435E61DE としてキューに登録) 5月28日 13:02:47 email2 postfix/qmgr[376]: 28A5D35E61DC: 削除
2) これは問題ありません: 私のクライアントはローカルアカウント(彼女の同僚)にメールを送信します。彼女はSMTP AUTHを使用しています。
5月28日 13:06:18 email2 postfix/smtpd[2519]: <censored>から接続 5月28日 13:06:18 email2 postfix/smtpd[2519]: 49CE735E61D4: client=<censored>、sasl_method=LOGIN、sasl_username=<[メールアドレス]> 5月28日 13:06:18 email2 postfix/cleanup[429]: 49CE735E61D4: message-id=<007201ce5b93$5df069c0$19d13d40$@cz> 5月28日 13:06:19 email2 postfix/qmgr[376]: 49CE735E61D4: from=<[メールアドレス]>、サイズ=10875、nrcpt=1 (キューがアクティブ) 5月28日 13:06:19 email2 postfix/smtp[2295]: 49CE735E61D4: to=<[メールアドレス]>、リレー=127.0.0.1[127.0.0.1]:10024、遅延=1.6、遅延=1.2/0/0/0.43、dsn=2.0.0、ステータス=送信済み (MTA(smtp:[127.0.0.1]:10025 からの 250 2.0.0): 250 2.0.0 Ok: CC61F35E61D7 としてキューに登録) 5月28日 13:06:19 email2 postfix/qmgr[376]: 49CE735E61D4: 削除
3) 問題: メールが自分のアカウント (同じサーバーですが、ドメインは異なります) に送信されましたが、SMTP AUTH は使用されていませんか?
5月28日 13:04:38 email2 postfix/smtpd[1433]: <censored>から接続 5月28日 13:04:38 email2 postfix/smtpd[1433]: NOQUEUE: 拒否: RCPT from <censored>: 554 5.7.1 <my_email>>: 受信者アドレスが拒否されました: 無効なHELO/EHLOです。FQDNまたはアドレスリテラルである必要があります。'xxx'ではありません。from=<[メールアドレス]> to=<my_address> proto=ESMTP helo= 5月28日 13:04:41 email2 postfix/smtpd[1433]: <censored> から切断
postfix 設定の一部:
smtpd_sender_restrictions = permit_mynetworks、 認証済み送信者ログインの不一致を拒否、 許可_sasl_認証 smtpd_recipient_restrictions = 不明な送信者ドメインを拒否、 不明な受信者ドメインを拒否、 非FQDN送信者を拒否、 非FQDN受信者を拒否、 非公開受信者を拒否、 チェックポリシーサービス inet:127.0.0.1:7777、 チェックポリシーサービス inet:127.0.0.1:10031、 許可_mynetworks、 許可_sasl_認証、 拒否する認証先 smtpd_helo_restrictions = permit_mynetworks、 許可_sasl_認証、 拒否_non_fqdn_helo_hostname、 無効なheloホスト名を拒否、 チェック_helo_access pcre:/etc/postfix/helo_access.pcre
出力を見るポストコンファレンスそして猫メイン.cfg
答え1
HELO/EHLOが発生する前にSMTP認証。サーバーが構成されている場合reject_non_fqdn_helo_hostname = yes
、無効なホスト名による接続はすべて拒否されます。前にSMTP AUTH 部分に到達します。
この拒否設定を維持することで、スパムメールはある程度は減りますが、正当なメールもブロックされてしまいます。詳しくはPostfixのドキュメントをご覧ください。無効な HELO ホスト名を拒否するそしてsmtp_helo_制限これをどのように動作させたいかを理解するためです。
答え2
smtpd_recipient_restrictions
すべてのクライアントが正常に動作しているという前提では問題ありません。そうではないので(正しいHELOを送信していない)、少なくとも次のようなものが必要です。
smtpd_recipient_restrictions = reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unlisted_recipient,
check_policy_service inet:127.0.0.1:7777,
check_policy_service inet:127.0.0.1:10031,
permit_mynetworks,
reject_unauth_destination
さらに良い点:
smtpd_recipient_restrictions =
check_recipient_access hash:/etc/postfix/access-recipient-rfc,
check_client_access cidr:/etc/postfix/access-client,
check_helo_access hash:/etc/postfix/access-helo,
check_sender_access hash:/etc/postfix/access-sender,
check_recipient_access hash:/etc/postfix/access-recipient,
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_sender_domain,
reject_non_fqdn_sender,
reject_unknown_recipient_domain,
reject_non_fqdn_recipient,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client ix.dnsbl.manitu.net,
# greylisting
check_policy_service inet:127.0.0.1:10023,
# policyd-weight
check_policy_service inet:127.0.0.1:12525,
reject_unauth_destination,
reject_unverified_recipient,
permit
さらに、すべての制限を に統合する必要がありますsmtpd_recipient_restrictions
。HELOはSASL認証の前に来る、 で SASL 認証を許可しても意味がありませんsmtpd_helo_restrictions
。
一般的には、 だけを使用するのが良い方法ですsmtpd_recipient_restrictions
。そこですべてを実行できるため、作業を繰り返す必要がなくなり、helo 後に終了する接続のネットワーク オーバーヘッドはそれほど大きくありません。
答え3
問題は policyd (cluebringer) にありました... 一見するとログからはわかりませんでしたが、拒否は postfix の制限によるものではなく、policyd によるものでした。
背景
cluebringers グループの internal_domains にはプライマリ ドメイン (インストール後) のみがあり、新しいドメインはすべてそこにありませんでした... この問題を解決するために、internal_domains を空にすることにし、すべてが期待どおりに動作するようになりました。
ご協力ありがとうございました!