On Wed, Aug 07, 2013 at 07:05:40AM -0600, LuKreme wrote: > Can the smtpd_recipient_restrictions in master.cf take the same > range of settings in identical syntax as in main.cf?
yes > I am wondering specifically if a declaration like: > > smtpd_recipient_restrictions=smtpd_recipient_restrictions=permit_my_networks,check_client_access > pcre:$config_directory/myfile.pcre,check_client_access > hash:$config_directgory/mydb,reject > > is syntactically OK in master.cf? First, no, because you repeated the "smtpd_recipient_restrictions=" part. Second, no, because you used spaces. Replace those with commas and remove the superfluous *= part, all should be well. But I prefer setting "submission_recipient_restrictions" in main.cf and using it in master.cf: submission inet n - n - - smtpd -o smtpd_tls_auth_only=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=$submission_relay_restrictions -o milter_macro_daemon_name=ORIGINATING -o syslog_name=postfix/submission Uh, I have mine as smtpd_relay_restrictions, but the same general idea applies. > In setting up restrictions to the submission port is there any > reason to (or not to) put in restrictions like > reject_non_fqdn_sender or reject_unauth_destination? reject_non_fqdn_sender could be a valid choice you might make, as would reject_unknown_sender_domain. Some sites prefer to accept anything from users' MUAs and let them end up as they will; others prefer to reject the obvious garbage and get the phone calls from bewildered users. I think you're going to get the phone calls eventually anyway, so personally, I prefer to have them when it's fresh and relevant and easy to find in the logs. OTOH I see no need for reject_unauth_destination when you're ending your $submission_recipient_restrictions with "reject" anyway. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: