Wietse Venema: > Wietse Venema: > > Melvin Vermeeren: > > > 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. > > > > By default, Postfix has > > > > smtpd_sasl_type = cyrus > > > > Why don't you set > > > > smtpd_sasl_type = dovecot > > > > and follow SASL_README instructions to configure Postfix as if it > > will use Dovecot? > > > > The only interaction betweeen Postfix and Dovecot is to get a list > > of authentication mechanisms, which Postfix wlll never use. I think > > that is a small sacrifice to make if you want to use Postfix in a > > manner that has never been tried before.
Yeah, this was what I would have done if I could not find another way to do
things. I was just thinking that technically speaking such configuration
should not be necessary with XCLIENT, which is why I mailed initially.
> If you have the resources to build Postfix from source code, then
> we can consider experiments with careful changes to the source to
> relax the requirement that smtpd_sasl_auth_enable=yes.
>
> We cannot simply remove the "if (var_smtpd_sasl_emable != 0)" check
> from all Postfix code, as that would likely result in segmentation
> faults in randomi places.
Sure, I can build it from source and/or patch the version I currently use,
which is 3.4.8 on Debian. Patches would be preferred to minimise the changes.
Not very familiar with Postfix sources, though they are easy to read.
In src/smtpd/smtpd_state.c I found the following which interested me:
/*
* Minimal initialization to support external authentication (e.g.,
* XCLIENT) without having to enable SASL in main.cf.
*/
#ifdef USE_SASL_AUTH
if (SMTPD_STAND_ALONE(state))
var_smtpd_sasl_enable = 0;
smtpd_sasl_set_inactive(state);
smtpd_sasl_state_init(state);
#endif
Likewise, in src/smtpd/smtpd_sasl_glue.c:
void smtpd_sasl_state_init(SMTPD_STATE *state)
{
/* Initialization to support external authentication (e.g., XCLIENT). */
state->sasl_username = 0;
state->sasl_method = 0;
state->sasl_sender = 0;
}
Just a wild guess: I get the feeling smtpd_check.c is relatively stand-alone
and doesn't really need SASL to be enabled, since it always performs safety
checks on the actual data such as:
if (state->sasl_username && state->sasl_username[0])
In src/smtpd/smtpd.c I notice there is "real" SASL logic going on, so it makes
sense to be wary here and not touch things unless needed.
The thing is, since we only want XCLIENT "SASL" sender checks, and not offer
actual authentication (AUTH), it would be best if smtpd_sasl_auth_enable
remained off and the checks will just automagically use the variables if set,
which is then only the case if XCLIENT is used, right?
SASL support would still need to be compiled in because #ifdef USE_SASL_AUTH
is used in many places, but I think this isn't a concern in practice.
In conclusion I believe "var_smtpd_sasl_enable" can be removed from src/smtpd/
smtpd_check.c completely, together with the "if (var_smtpd_sasl_enable)"
conditionals. Could you post your thoughts on this?
Thanks again,
Melvin.
signature.asc
Description: This is a digitally signed message part.
