問題は、MS Outlook2007が特定のドメインが1つしかないという奇妙な理由でSMTPAUTHを送信しないことのようです。
私は自分のドメインと数十のクライアントドメインに対してiRedMailサーバー(ストックdebian 7/wheezy、接尾辞2.9.6-2を使用)を実行しています。問題は、クライアントが自分自身(自分の電子メールだけでなくドメイン全体)に電子メールを送信できないことです-reject_non_fqdn_helo_hostname
が原因で拒否されますが、クライアントはSMTP AUTHを使用しており、正しく設定されているため、バイパスする必要がありますFQDNチェック。 MUAが私と私の同僚の電子メールアドレスにのみSMTPAUTHを使用していないようです。
誰かがこれを見たことがありますか?この問題を回避するにはどうすればよいですか?どんな入力でも大歓迎です!
MUAに接続されているのでしょうか?彼女はOutlook(Expressではなく)を使用していますか?
さまざまな状況を示すログの次の断片を見てください。すべてが同じ構成/同じMUA/IPでキャッチされました...:
1)これは問題ありません:私のクライアントはサードパーティのサーバーに電子メールを送信します。 SMTPAUTHを使用する
5月28日13:02:13email2 postfix/smtpd [1191]:<打ち切り>から接続 5月28日13:02:13email2 postfix/smtpd [1191]:28A5D35E61DC:client = <打ち切り>、sasl_method = LOGIN、sasl_username = <[email protected]> 5月28日13:02:26email2 postfix/cleanup [1435]:28A5D35E61DC:message-id = <006c01ce5b92 $ d33805e0 $ 79a811a0 $ @cz> 5月28日13:02:44email2 postfix/qmgr [376]:28A5D35E61DC:from = <[email protected]>、size = 4392922、nrcpt = 7(キューがアクティブ) 5月28日13:02:44email2 postfix/smtp [1580]:28A5D35E61DC:to = <[email protected]>、relay = 127.0.0.1 [127.0.0.1]:10024、delay = 32、 delays = 31/0/0/0.88、dsn = 2.0.0、status = sent(250 2.0.0 from MTA(smtp:[127.0.0.1]:10025):250 2.0.0 Ok:キューに入れられてB061435E61DE) 5月28日13:02:47email2 postfix/qmgr [376]:28A5D35E61DC:削除
2)これはOKです:私のクライアントはローカルアカウント(彼女のコレク)に電子メールを送信します。彼女はSMTPAUTHを使用しています
5月28日13:06:18email2 postfix/smtpd [2519]:<打ち切り>から接続 5月28日13:06:18email2 postfix/smtpd [2519]:49CE735E61D4:client = <打ち切り>、sasl_method = LOGIN、sasl_username = <[email protected]> 5月28日13:06:18email2 postfix/cleanup [429]:49CE735E61D4:message-id = <007201ce5b93 $ 5df069c0 $ 19d13d40 $ @ cz> 5月28日13:06:19email2 postfix/qmgr [376]:49CE735E61D4:from = <[email protected]>、size = 10875、nrcpt = 1(キューがアクティブ) 5月28日13:06:19email2 postfix/smtp [2295]:49CE735E61D4:to = <[email protected]>、relay = 127.0.0.1 [127.0.0.1]:10024、delay = 1.6、 delays = 1.2/0/0/0.43、dsn = 2.0.0、status = sent(250 2.0.0 from MTA(smtp:[127.0.0.1]:10025):250 2.0.0 Ok:キューに入れられてCC61F35E61D7) 5月28日13:06:19email2 postfix/qmgr [376]:49CE735E61D4:削除
3)問題、SMTP AUTHを使用していない私のアカウント(同じサーバー、ただし異なるドメイン)に電子メールが送信されました???:
5月28日13:04:38email2 postfix/smtpd [1433]:<検閲>から接続 5月28日13:04:38email2 postfix/smtpd [1433]:いいえ:拒否:RCPT <検閲>から:554 5.7.1 <my_email >>:受信者のアドレスが拒否されました:無効なHELO/EHLO; 'xxx'ではなく、FQDNまたはアドレスリテラルである必要があります。 from = <[email protected]> to = <my_address> proto = ESMTP helo = 5月28日13:04:41email2 postfix/smtpd [1433]:<検閲済み> [.____から切断します。 ]
後置構成の一部:
smtpd_sender_restrictions = permit_mynetworks、 react_authenticated_sender_login_mismatch、 permit_sasl_authenticated smtpd_recipient_restrictions = react_unknown_sender_domain_、 react_non_fqdn_recipient、 react_unlisted_recipient、 check_policy_service inet:127.0.0.1:7777、 check_policy_service inet:127.0.0.1:10031、 permit_mynetworks、[.____ 、 require_unauth_destination smtpd_helo_restrictions = permit_mynetworks、 permit_sasl_authenticated、 react_non_fqdn_helo_hostname、 react_invalid_helo_hostname、 check_helo_access pcre:/etc/postfix/helo_access.pcre
postconf および cat main.cfg の出力を参照してください
問題はポリシー(cluebringer)にありました...最初の外観のログからは確認されませんでした。拒否は接尾辞の制限からではなく、ポリシーからのものでした。
背景
Cluebringersグループinternal_domainsにはプライマリドメイン(インストール後)のみがあり、すべての新しいドメインはありませんでした...問題を解決するために、internal_domainsを空にすることにしました。これで、すべてが期待どおりに機能します。
よろしくお願いします!
HELO/EHLOが発生しますbefore SMTP認証。サーバーがreject_non_fqdn_helo_hostname = yes
で構成されている場合、サーバーは無効なホスト名を持つ接続を拒否しますbefore SMTPAUTH部分に到達します。
この拒否を維持すると、一部のスパムが削減されますが、多くの正当なメールもブロックされます。 reject_invalid_helo_hostname および smtp_helo_restrictions のPostfixドキュメントを詳しく調べて、これをどのように機能させるかを理解する必要があります。
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認証の前に来る なので、smtpd_helo_restrictions
でSASL認証を許可することはできません。
一般に、smtpd_recipient_restrictions
だけを使用することをお勧めします。ここですべてを実行できるため、繰り返し作業を省くことができ、helo後に終了する接続のネットワークオーバーヘッドはそれほど大きくありません。