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