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:
