On 3/9/2015 10:46 AM, Earl Killian wrote: > On 2015/3/9 08:12, Noel Jones wrote: >> You have misunderstood the purpose of smtpd_relay_restrictions. >> Your mail is rejected by the final "reject" you placed. >> >> *ALL* mail is evaluated by smtpd_relay_restrictions, and unless you >> have very unusual relay requirements, you should either set it >> empty, or use the suggested safety net: >> smtpd_relay_restrictions = >> permit_mynetworks, >> permit_sasl_authenticated, >> reject_unauth_destination >> >> >> >> -- Noel Jones > Thank you for correcting my misunderstanding; I understand it now. I > gather then, since they are both used, that the only purpose of the > new one is to have a default value that protects someone from > leaving things out of smtpd_recipient_restrictions. > > You suggested it would very unusual to set it, but it seems like > permit_tls_clientcerts would be one reason. I am thinking of setting > it to > smtpd_relay_restrictions = > reject_non_fqdn_recipient > reject_unknown_recipient_domain > reject_unknown_sender_domain > permit_mynetworks > permit_tls_clientcerts > reject_rbl_client bl.blocklist.de > permit_sasl_authenticated > reject_unauth_destination > where the RBL is used to prevent password probing before the > permit_sasl_authenticated. I would then remove those same lines from > smtpd_recipient_restrictions to avoid redundancy. Does this sound > reasonable? >
Put only restrictions related to relaying in smtpd_relay_restrictions. It is not intended for spam or access control, only as a relay safety net. It's certainly OK to add permit_tls_certclients, but the other restrictions belong elsewhere. -- Noel Jones
