|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: Update: plug-in SASL support (20051217-nonprod)
From: Andreas Winkelmann (ml
awinkelmann.de)
Date: Fri Dec 23 2005 - 03:26:33 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Am Friday 23 December 2005 02:01 schrieb Wietse Venema:
> > > > > The plug-in interface (see manual pages below) was unavoidably
> > > > > influenced by the Cyrus SASL library. It remains to be seen if
> > > > > this interface is convenient for other SASL implementations (I'm
> > > > > thinking of Dovecot and Bieringer).
> > > >
> > > > One thing I would need is some place to configure path for
> > > > dovecot-auth's UNIX socket. I could probably use appl_name or
> > > > security options for this since I don't need them for anything, but
> > > > that'd be pretty kludgy. Maybe some sasl_init_settings parameter?
> > >
> > > There is a legitimate need for every SASL plug-in to forward some
> > > configuration information from Postfix (main.cf) to the underlying
> > > SASL implementation.
> > >
> > > The Cyrus SASL "application name" and "security options" are examples
> > > of such implementation specific information; Postfix simply passes
> > > them through to the plug-in, without inspection. The plug-in
> > > understands the syntax of Postfix's SASL security options, but
> > > leaves it up to Cyrus SASL to make sense of the "application name".
> > >
> > > The "application name" information currently is not configurable
> > > but probably should be. If Cyrus uses it to specify the the base
> > > name of the smtpd.conf file, then Dovecot could use it for the
> > > UNIX-domain socket pathname. In both cases Postfix passes the
> > > underlying implementation some kind of location information.
> > >
> > > For example, we could name this parameter
> > >
> > > smtpd_sasl_pathname
> > >
> > > Getting the default values right isn't quite so simple.
> > >
> > > The problem is that SASL implementation specific Postfix configuration
> > > parameter names or defaults would defeat the purpose of SASL
> > > plug-ins: to provide functionality without source code modification.
> > > Ideally the plugins would be run-time linked, like Debian's run-time
> > > linking of SQL etc. map support.
> >
> > Hmm, maybe I do not understand this, but this Application Name is already
> > configurable. The Option is smtpd_sasl_application_name. It is an Option
> > implemented in the beginning of 2004. Is it intent to change the name
> > from one version to another, without some time where both options run in
> > parrallel?
>
> I suggest that you study the SASL_README documentation.
Ok, maybe I find something which I didn't read before, thx.
--
Andreas
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]