Prev: TLS Root Certificate Problem
Next: postdrop?
From: Wietse Venema on 6 Jan 2010 10:11
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

From: jeff geng on 6 Jan 2010 21:06
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 <wietse(a)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
>
From: Wietse Venema on 6 Jan 2010 22:15
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 <wietse(a)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
> >

 | 
Pages: 1
Prev: TLS Root Certificate Problem
Next: postdrop?