On Saturday, 21 March 2020 15:59:45 CET Wietse Venema wrote:
> Melvin Vermeeren:
> > > connect from localhost[127.0.0.1]
> > > warning: restriction `reject_authenticated_sender_login_mismatch'
> > > ignored:
> > > no SASL support
>
> This means that Postfix is built without any SASL support,
> or that you have "smtpd_sasl_enable=no".
>
> Wietse
>
> Code sample:
>
> #ifdef USE_SASL_AUTH
> } else if (is_map_command(state, name, CHECK_SASL_ACL, &cpp)) {
> if (var_smtpd_sasl_enable) {
> if (state->sasl_username && state->sasl_username[0])
> status = check_sasl_access(state, *cpp, def_acl);
> } else
> #endif
> msg_warn("restriction `%s' ignored: no SASL support", name);
> } else ...Assuming "smtpd_sasl_enable" is the same as "smtpd_sasl_auth_enable" (current docs only have the latter) I came to the same conclusion initially, I also grepped the source code and indeed saw the logic in the code sample given. Note that the initial mail continues after this observation and "smtpd_sasl_auth_enable" is set to "yes". Only after that change does the real problem come to light, which is what the initial mail really is about. To be specific the problem is that it appears impossible to enable SASL without configuring a real, working, authentication back-end, which is not needed if only XCLIENT-style SASL is used I believe. Thanks, Melvin.
signature.asc
Description: This is a digitally signed message part.
