[Dovecot] Additional passdb result status

[Jürgen Pabel]

Hi,

I am replying to my own message because it's probably the "cleanest"
reply since I am not subscribed to the mailing list and thus can't reply
to Charles' message itself.

> What specifically is the *purpose* of this?

To encrypt the data on the server (like the zlib plugin does for
compression). Said value will be password used to unlock/decrypt the
encryption key stored on the server. (I have implemented several
cryptographic software components, so I believe that I understand what
all is required for something like such a plugin to be implemented
correctly).

> I think it is usually preferred that you do things like this against 
> either the current shipping/stable branch (2.1.x), or even hg (2.2).. 
> much better chance that it would be accepted.

Agreed - I'm just developing on Ubuntu 12.04 which has 2.0. However,
porting patches from 2.0 to 2.1/2.2 shouldn't be too hard from what I've
seen so far.

Cheers,
Jürgen


Am Sonntag, den 24.06.2012, 22:37 +0200 schrieb Jürgen Pabel:
> Dear Dovecot-Team,
> 
> I am implementing a plugin (for the pop3/imap process) that requires
> some data to provided from the authentication phase (a derivative of the
> password). For that, I have now implemented a passdb plugin that
> generates this data and I would like to "pass" this data down to the
> mail process (pop3/imap) via extra_fields in the reply of the
> authentication. The general idea is that my custom passdb plugin
> calculates the data, sets the extra_field and returns some error
> (authentication was not successful) so that the "real" passdb backend
> can be invoked to "really" validate the authentication data. 
> 
> However, in auth_request_handle_passdb_callback() the extra_fields are
> reseted unless the return code is PASSDB_RESULT_USER_DISABLED. But if
> that return code is used then any following passdb's aren't invoked any
> more - which makes sense with respect to user authenticiation. I would
> therefore like to propose that some IGNORE/CONTINUE-status to be
> introduced in auth/passdb.h, that would be handled in that extra_fields
> and possible other values are not reseted in order to allow such
> propagation of data from authentication process down to the mail process
> (which could be extracted from the reply string by parsing it).
> 
> As a further implementation alternative (to the parsing of the reply
> string), I also propose that some new "environment" item be introduced
> (in auth_request) in order to allow such data passing in a generic
> manner. 
> 
> I hope you consider my proposal to be reasonable. If desired, I could
> implement this myself and provide a patch for merging (based on 2.0.x).
> If my proposal is generally unfavored, it would be great if any
> alternative approaches for my situation were suggested. Thanks.
> 
> Regards,
> Jürgen
> 
> PS: please reply to my e-mail (or CC me), as I have not subscribed to
> the dovecot list
>