Wietse:
If We modify
#ifdef USE_SASL_AUTH
if (var_smtpd_sasl_enable)
if (got_proto == 0)
smtpd_sasl_auth_reset(state);
#endif
to
#ifdef USE_SASL_AUTH
if (var_smtpd_sasl_enable)
if (got_login == 0)
smtpd_sasl_auth_reset(state);
#endif
the got_login will be used.But this is not the key issues.
If nginx will support SASL_USER and SASL_METH parameters, it would be best.
If you can put something into Postfix for current nginx We will be very
grateful to you.
Thank you.
jeff geng
2010/1/6 Wietse Venema <wie...@porcupine.org>
> Wietse Venema:
> > > > + UPDATE_STR(state->sasl_username, attr_value);
> > > > + printable(state->sasl_username, '?');
> > > > + UPDATE_STR(state->sasl_method, "xclient");
> > > >
> > > > Why not use the real authentication mechanism?
> > > >
> > >
> > > Otherwise, if XCLIENT pass LOGIN parameter, state->sasl_username and
> > > state->sasl_method will be updated, postfix will deem it as an
> authenticated
> > > client.
> > > So , if nginx pass through LOGIN parameter, postfix should identify it
> as a
> > > authenticated client, but postix XCLIENT can't support this parameter.
> >
> > XCLIENT can support both the login name and the authentication
> > method name, and therefore nginx should pass both to Postfix.
>
> I noticed that the nginx reverse proxy implements TLS, so it makes
> sense to plan for future XCLIENT extensions that propagate TLS
> attributes, besides the extension for SASL that you introduced with
> this thread.
>
> This means using something like SASL_USER and SASL_METH for the
> proposed SASL attributes, and TLS_XXX for future TLS attributes,
> so that there will be no conflicts between the names.
>
> I keep whining about the SASL authentication method, because that
> information is used by the Postfix "permit_sasl_authenticated"
> access control feature. It would therefore be wrong to set this to
> a fixed value like your patch does.
>
> Now that I understand how your patch is supposed to work, I can
> put something into Postfix, but it would help if we can agree on
> the attribute names and on the protocol details.
>
> I am sure that there are a few gotchas when you poke Postfix SASL
> attributes without proper initialization and cleanup of the Postfix
> SASL layer, but that can be fixed by adding a few functions to that
> SASL layer that handle support for proxied attributes.
>
> Wietse
>
