前回の記事の設定で spam は大変効率良く弾けるようになったのだけれど、メールを受け取るべきサイトの幾つかも同時に弾いてしまっているので、その救済。
毎日 maillog を観察して、こういったエラーを個別に救っていく。
(1)
450 4.7.1 Client host rejected: cannot find your hostname, [aaa.bbb.ccc.ddd]; from=<dareka@dokka> to=<watashi@uchi> proto=ESMTP helo=<nanka.tekito.ni.tsuiteru>
この例の場合2通りの可能性がある。
a. aaa.bbb.ccc.ddd が何故か逆引きできない。
b. aaa.bbb.ccc.ddd を逆引きした結果の dokka を正引きすると、aaa.bbb.ccc.ddd と何故か一致しない。
a の場合、次のように回避。
i) /etc/postfix/client_access に次のような行を追加
aaa.bbb.ccc.0/24 OK
ii) コマンド行から次を実施
cd /etc/postfix; postmap client_access
iii) postfix の再起動
b の場合、名前解決できるように、次の行を /etc/hosts にでも追加する。
aaa.bbb.ccc.ddd dareka.dokka
(2)
450 4.7.1 <mail2.moshimo.com>: Helo command rejected: Host not found; from=<dareka@dokka> to=<watashi@uchi> proto=ESMTP helo=<nanka.tekito.ni.tsuiteru>
相手が HELO/EHLO で指定してきた nanka.tekito.ni.tsuiteru が何故か正引きできない。
次のように回避。
i) /etc/postfix/helo_access に次のような行を追加。
nanka.tekito.ni.tsuiteru OK
ii) コマンド行から次を実施
cd /etc/postfix; postmap helo_access
iii) postfix の再起動
(3)
(a)
450 4.1.7 <dareka@dokka>: Sender address rejected: unverified address: connect to dokka[aaa.bbb.ccc.ddd]:25: Connection timed out; from=<dareka@dokka> to=<watashi@uchi> proto=ESMTP helo=<nanka.tekito.ni.tsuiteru>
送信側のメール・アドレス dareka@dokka が本当にいるのかどうかを送信側に問い合わせようとしたが、何故か向うのサーバーに繋がらなかったので、その人の存在が確認できなかった。
(b)
450 4.1.7 <dareka@dokka>: Sender address rejected: unverified address: host mx.dokka[aaa.bbb.ccc.ddd] said: 550 5.7.1 No such user! (in reply to RCPT TO command); from=<dareka@dokka> to=<watashi@uchi> proto=ESMTP helo=<nanka.tekito.ni.tsuiteru>
送信側のメール・アドレス dareka@dokka が本当にいるのかどうかを送信側に問い合わせたが、何故か向うのサーバーはそんな人知らないって言った。
(c)
450 4.1.7 <dareka@dokka>: Sender address rejected: unverified address: host mx.dokka[aaa.bbb.ccc.ddd] said: 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 https://hoge.dokka/nanka-kaitearu.html; from=<dareka@dokka> to=<watashi@uchi> proto=ESMTP helo=<nanka.tekito.ni.tsuiteru>
送信側のメール・アドレス dareka@dokka が本当にいるのかどうかを送信側に問い合わせたが、何故か向うのサーバーはメール・アドレス打ち間違えて無い? って言った。
…大体こんな感じのバリエーション。いづれにせよ、この手のメールを受信する必要があるのなら、次のように回避。
i) /etc/postfix/sender_access に次のような行を追加
dareka@dokka OK
… もし、dareka の部分が毎回変わるようなら dareka@ を取り除いて
dokka OK
とする。
ii) コマンド行から次を実施
cd /etc/postfix; postmap sender_access
iii) postfix の再起動
ところでこの記事何周遅れなんだろうね?
見方によっては、15年位遅れてるんじゃないか?
まぁ、だけどうちは比較的最近漸く qmail から postfix に乗り換えたからね。
今こういうことをやらなきゃならない。
2019年5月28日火曜日
2019年5月6日月曜日
postfix と spam
ずっと所謂昔で言う所の Google Apps を、メール配送含めて使って来たのだけれど、あんまメリット無くなってきたなぁって感じで解約しようと思いました。
で、メール・サーバーを Google さんから自前サーバー上の Postfix に移行したのだけれど、ちゃんと設定すると rbl とか使わなくても結構 spam 弾けるのね。
激減しました。
#address_verify_poll_delay = 3s
# qmail responds slow for those recipients query
address_verify_poll_delay = 59s
今はこんな(※ 間違ってないだろうな?)。
※ 05/07 注: 一部企業等の sender address が存在しない no-reply@XXX になってたので、 smtpd_sender_restrictions に check_sender_address を加え、ここにホワイトリストを書くことにしました。若干面倒。
※ 05/19 注: 結局 recipient_restriction 以外には全部ホワイトリストが必要な模様。
で、メール・サーバーを Google さんから自前サーバー上の Postfix に移行したのだけれど、ちゃんと設定すると rbl とか使わなくても結構 spam 弾けるのね。
激減しました。
smtpd_client_restrictions =
permit_mynetworks,
check_client_access cidr:/etc/postfix/client_access,
reject_unknown_client,
permit
smtpd_helo_restrictions =
check_helo_access hash:/etc/postfix/helo_access,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_unknown_hostname,
permit
smtpd_sender_restrictions =
permit_mynetworks,
check_sender_access hash:/etc/postfix/sender_access,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unverified_sender,
permit
smtpd_recipient_restrictions =
permit_mynetworks,
reject_non_fqdn_recipient,
reject_unauth_destination,
reject_unknown_recipient_domain,
reject_unknown_client_hostname,
reject_unverified_recipient,
permit
#address_verify_poll_delay = 3s
# qmail responds slow for those recipients query
address_verify_poll_delay = 59s
今はこんな(※ 間違ってないだろうな?)。
※ 05/07 注: 一部企業等の sender address が存在しない no-reply@XXX になってたので、 smtpd_sender_restrictions に check_sender_address を加え、ここにホワイトリストを書くことにしました。若干面倒。
※ 05/19 注: 結局 recipient_restriction 以外には全部ホワイトリストが必要な模様。
登録:
投稿 (Atom)