Hi, >> I've just noticed I'm using reject_rbl_client and have postscreen >> using the RBLs as well. I'll remove the ones from the >> smtpd_client_restrictions, but could this possibly be causing mail to >> be rejected even when connecting via the submission port? > > My two cents on that: when implementing postscreen, leave your > smtpd_*_restrictions alone. They were working before, so keep them in > reserve. For example, when under stress, it is possible that DNSBL > queries will not return before the 2-second timeout period. In the > time it takes to pass the connection to smtpd and for smtpd to do > checks, those queries may have returned and been cached. It's very > cheap to do a DNS query from your local cache.
Is it not the case that having it in both smtpd_*_restrictions and postscreen consumes process resources? It also means that I must create exceptions in two different places, should it ever be necessary. > Listing $transport_maps here can become very dangerous if you later > decide to use transport_maps for other purposes. A popular idea is to > use a special throttled transport for Yahoo ... oops, yahoo.com > becomes one of your relay_domains. I have the following in my transport map: example.com local: .example.com local: This was done a long time ago when this system used to be a dual-instance postfix scenario and I couldn't figure out how to do it without this. > relay_domains without relay_recipient_maps can cause backscatter. You > need either per-address ONLY transport_maps or recipient address > verification. We can't see into your transport_maps, and there is no > evidence of verification being done. Is this why I have the following in the logs? Mar 6 07:17:23 portal postfix/trivial-rewrite[4328]: warning: do not list domain example.com in BOTH virtual_alias_domains and relay_domains In /etc/postfix/virtual I have the following: example.com VIRTUALDOMAIN am...@example.com farroua l...@example.com colonl j...@example.com hannahj ci...@example.com barkerc I thought removing it from relay_domains was the right thing to do, but I believe it broke something when I did it last, and since it's working, I've left it alone. Obviously would like to fix it. >> smtpd_recipient_restrictions = reject_non_fqdn_recipient, >> check_client_access hash:/etc/postfix/client_checks_special, >> check_sender_access hash:/etc/postfix/sender_checks_special, > > These access(5) lookups MUST NOT return a permit result. If they do, > you are allowing relay. > > http://www.postfix.org/SMTPD_ACCESS_README.html#danger I have entries like this in my client_checks files: 192.168.1.100 OK 192.168 554 Take a hike! southmarketing.com.br OK .southmarketing.com.br OK In sender_checks I have similar: someu...@example3.tld OK 173.245.204.0/23 REJECT >> reject_non_fqdn_sender, permit_mynetworks, permit_sasl_authenticated, >> reject_unauth_destination, reject_unknown_sender_domain, >> reject_unknown_recipient_domain, >> reject_invalid_helo_hostname, check_recipient_access >> pcre:/etc/postfix/relay_recips_ecartis, check_client_access >> hash:/etc/postfix/client_checks, check_sender_access >> hash:/etc/postfix/sender_checks, check_recipient_access >> pcre:/etc/postfix/relay_recips_access, reject_rbl_client >> zen.spamhaus.org, reject_rbl_client psbl.surriel.com, permit > > But there it is, long after permit_sasl_authenticated, so an > authenticated client is not affected. We can only guess that > PattyTHINK above failed to authenticate. Would this be represented in the logs in some way, or only after adding the "-o syslog=postfix/submission" to master.cf and its lack of presence? >> --master.cf-- >> submission inet n - n - - smtpd >> -o smtpd_tls_security_level=encrypt >> -o smtpd_sasl_auth_enable=yes >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject > > You might also want to override your smtpd_recipient_restrictions > here. You can define a variable in main.cf, for example: > > submission_recipient_restrictions = [ stuff that you want applied > against submission users ], permit_sasl_authenticated, reject > > And then use it here: > -o smtpd_recipient_restrictions=$submission_recipient_restrictions I'm not sure I understand why I would want to do this? >> -o milter_macro_daemon_name=ORIGINATING > > This also needs " -o syslog_name=postfix/submission", which is a > recently-added default. Thus we can see for sure that we're on > submission and not smtp. Okay, I've added it. Should it then look like this after adding? Mar 6 21:33:17 portal postfix/submission/smtpd[15023]: connect from rrcs-204-210-162-21.central.biz.rr.com[204.XXX.YYY.21] Thanks, Alex
