On 5/6/2009 9:03 AM, Jorey Bump wrote: >>>> I believe newer versions (I'm on 2.5.6) should be something like: >>>> >>>> submission inet n - n - - smtpd >>>> -o smtpd_tls_security_level=encrypt >>>> -o smtpd_tls_auth_only=yes >>>> -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>>> The OP might also benefit from changing the last line to: >>> >>> -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject >>> >>> This will override the corresponding smtpd_recipient_restrictions in >>> main.cf and provide a simpler configuration appropriate to the >>> submission service. Tweak as needed. >> Hmmm... I'm wondering what the effective difference is (maybe I should >> change mine too?)... > In this particular case, either will probably just work. Probably? Well, I tested mine when I initially set it up and it does indeed work... > The main advantage is that it matches the approach used in main.cf > (handling all restrictions in smtpd_recipient_restrictions), so the > override makes it possible to avoid restrictions specifically > targeting the server's role as an MX. > > 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'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... Thanks, -- Best regards, Charles
