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 >
