jeff geng:
> 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.
I'll give it a try. I looked at nginx and I think it does a good job.
Wietse
> 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
> >
