Sahil Tandon wrote, at 01/08/2009 11:37 PM: > Jeff Weinberger wrote: > >> Also you noted: >> >>>> In the final step of my scenario, that's the behavior I want to >>>> achieve. >>>> Will that simple step work? >>> Yes. You can completely disable submission on port 25 and prevent >>> relaying to destinations you don't accept by hosts outside of >>> mynetworks. >> Does smtpd_sasl_auth_enable = no completely disable submission and >> prevent relaying for hosts I don't accept? or is there more I have to >> make sure I do? > > This disables submission via SASL authenticated clients on port 25.
My statement was an overqualified mouthful, while Sahil's response to your followup is succinct (and correct), but only one part of the puzzle. You need to understand that authentication (establishing a user's identity) is separate from authorization (granting access to a resource). smtpd_sasl_auth_enable = yes provides a user the opportunity to establish an identity, but doesn't allow relaying by itself. That is achieved by the appropriate placement of permit_sasl_authenticated (among other things). I mention this because you have another option that may make more sense in your scenario: During migration, leave smtpd_sasl_auth_enable = yes in main.cf, but remove permit_sasl_authenticated from any of the smtpd_*_restrictions in main.cf (after you've properly configured and tested the submission service in master.cf, of course). The advantage of this is that users will be allowed to authenticate, but will not be able to relay to external destinations. This will be easier to troubleshoot, and based on the relaying denied error, you can simply instruct your users to change their outgoing SMTP to use port 587. In addition, they will probably still be able to send email to you, if your server also handles mail for your destination (or allows unauthenticated relaying to the MX that does). Once all current users have migrated, you can set smtpd_sasl_auth_enable = no, if you like (unless you want the same environment in place for new users). The danger of beginning migration with smtpd_sasl_auth_enable = no is that the users may mess up their configurations trying to fix it, and they won't have an immediate way to contact you via email.
