Nick Sharp wrote: >> A sample submission entry in master.cf: >> >> submission inet n - n - - smtpd >> -o smtpd_tls_security_level=encrypt >> -o smtpd_tls_auth_only=yes >> -o smtpd_sasl_auth_enable=yes >> -o broken_sasl_auth_clients=yes >> -o >> receive_override_options=no_header_body_checks,no_address_mappings >> -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject >> -o content_filter=lmtp-amavis:[127.0.0.1]:10026 >> >> The key is the smtpd_recipient_restrictions' permit_sasl_authenticated >> coming first or early. Thus, port 587 users who authenticate pass the >> green light. >> >> > > Just tried this configuration and moved client restrictions to master.cf > under smtp; > smtp inet n - - - 50 smtpd > -o cleanup_service_name=pre-cleanup > -o content_filter=procmail:filter > -o smtpd_client_restrictions=$master_client_restrictions > submission inet n - n - - smtpd > -o smtpd_tls_security_level=encrypt > -o smtpd_tls_auth_only=yes > -o smtpd_sasl_auth_enable=yes > -o broken_sasl_auth_clients=yes > -o > receive_override_options=no_header_body_checks,no_address_mappings > -o > smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject > > main.cf changes; > master_client_restrictions=permit_sasl_authenticated,permit_mynetworks > reject_rbl_client blackholes.easynet.nl, > <big list of rbls> > > #smtpd_client_restrictions = > > and I still get Client Host: Access denied in the logs from everywhere > without permit_mynetworks in the submission smtpd_client_restrictions, that > just makes it work from our networks, but not from the wireless broadband. > > So I am concluding that it is not acknowledging sasl_authentication for some > reason? (I am now not seeing any rbl failed requests though.. probably since > its not asked to check anymore. > > Any ideas? I am a little stumped, so any suggestions are welcomed with open > arms (and 10 minutes to test them :) >
With the number of restrictions you have, it is difficult to tell without a full, unaltered log entry. You may replace the user with "u...@example.com" if you like, but the rest is crucial to understand *which* action caused the reject.
