Charles Marcus wrote, at 05/06/2009 09:38 AM: > On 5/6/2009 9:03 AM, Jorey Bump wrote: >> Another minor advantage is that the configuration will continue to work >> if permit_sasl_authenticated is removed from >> smtpd_recipient_restrictions in main.cf (if the decision is ever made to >> disallow submission on port 25, restricting authenticated users to >> submission port 587). > > I thought that it would still work this way when it is set to > client_restrictions? Why would removing this restriction from > recipient_restrictions in main.cf cause this setting in master.cf to no > longer reject unauthenticated sasl sessions on the submission port?
It will still reject (most) unauthenticated submissions, since they can't get past your smtpd_client_restrictions. That's not the issue. If the smtpd_recipient_restrictions in main.cf are not overridden in master.cf for the submission service, then they still apply. So, even if your submission service's smtpd_client_restrictions contains permit_sasl_authenticated, the authenticated user's messages to external domains will likely be rejected during RCPT TO if permit_sasl_authenticated is removed from smtpd_recipient_restrictions in main.cf (thanks to Sahil for pointing this out in an earlier thread). In other words, getting past smtpd_client_restrictions doesn't guarantee getting past smtpd_recipient_restrictions. You can test this by temporarily removing permit_sasl_authenticated from smtpd_recipient_restrictions in main.cf and attempting to relay a message to an external domain as an authenticated user via the submission port. With your current settings, the message should be rejected (unless permitted by something else, like mynetworks). If you're never going to disallow submission on port 25, don't worry about it. As always, YMMV depending on your configuration. >> It's slightly more portable, but only when assuming the common practice >> of handling all restrictions in smtpd_recipient_restrictions. > > Understood with respect to main.cf, but we're talking about master.cf. I > really thought that it was better to be more specific in master.cf in > this case. Hmm, guess I have more reading to do... Yes, it is. That's why you have to consider the global settings in main.cf and override them appropriately in master.cf.
