On 23.11.22 22:24, Doug Hardie wrote:
I am trying with the postscreen dns lookup disabled. Here is the main.cf
section:
# Incoming restrictions and Implement postfwd
incoming_smtpd_restrictions =
check_policy_service inet:127.0.0.1:10040,
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
permit_mynetworks,
check_recipient_access hash:/usr/local/etc/postfix/tempfail,
reject_unauth_destination,
reject_unverified_recipient
reject_rbl_client bl.spamcop.net,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client zen.spamhaus.org,
permit
smtpd pass - - n - 50 smtpd
-o smtpd_recipient_restrictions=$incoming_smtpd_restrictions
strange combination, but it should work.
I personally recommend to use smtpd_recipient_restrictions in main.cf and if
needed, override them for smtps/submission services.
However, I seem to be doing the dns for all received emails. I see the log
message for user User unknown in virtual alias table, and dns requests
with that same timestamp for spamcop, barracudacentral and spamhaus. I am
suspecting I am missing a reject statement that will reject the email when
the user is not in the virtual alias table that needs to be before the rbl
rejects. I thought that reject_unverified_recipient would do that, but
apparently not.'
you should use reject_unverified_recipient instead of
reject_unverified_recipient, they have different use which is why you get
DNS lookups prior recipient being rejected.
Also, I want to repeat that it's better to reject DNSBLs at postscreen
level, even if you see more DNSBL lookups
- currently you are telling spambots which users do/don't exist
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
He who laughs last thinks slowest.
