Elliot F wrote:
Done.  Configuration can be given via the 'ldap' config file, or given as
arguments to the plugin.  If both are set, the plugin arguments override the
configuration file settings.

One problem is that if a configuration value has a space (or spaces) in it, it
breaks.  This could be a problem for many people's LDAP configs, as many DNs
have spaces, and if/when I add the configurable filter (which could very likely
have spaces,) that would be a problem as well.

That's what quotes are for. The parameters are not strictly whitespace delimited, but will respect quotes when splitting into the array.


So then if a user can't be found (either in mysql or LDAP or whatever) should
the plugin returned DENY (under the assumption it's the only auth plugin) or
DECLINED (if there is more than one way for the user to AUTH)?

All auth plugins should normally return DECLINED unless it is intended to be the only possible auth plugin (and even then, you don't need to return DENY, see below).



For that matter, should the auth plugin ever return DENY? If there is more than one auth plugin (for whatever reason), then if the first fails, none of the others will run. A corner case, yes, but interesting anyway.

An auth plugin should only return DENY if you choose to immediately decide this attempt is invalid, for example the username matches but the password doesn't (say you know that users will only ever be located in a single database). Even so, see below.


If a DECLINED is returned, it simply means the relayclient variable won't be set
for the connection, and the user won't be able to relay.  I wonder how that
would affect the auth portion, as the client should get a success/fail after
trying to auth against the SMTP server.

For each of the phases of a SMTP transaction, there is a master process which actually dispatches the plugins for that phase. In the auth case, it is the Qpsmtpd::Auth::SASL method. This actually performs the negotiation with the client based on the possible (registered) AUTH methods and then passes the client responses to each of the auth plugins in turn. If any plugin in the chain returns OK, the SASL() method responds 235 (success) and sets the relay_client flag. If none of the plugins respond OK (i.e. all responded DECLINED), then the SASL() method responds 535 (failure) and the remote client gets to try again.


You can see some documentation for auth plugins here:

        $ perldoc lib/Qpsmtpd/Auth.pm

though I notice a few typos I need to fix (like DECLINED is missing the terminal "D")...

HTH

John

Reply via email to