All -
I've had some time to play with this and I am making some progress. I've made some preliminary design decisions, which I thought I would post to the list so I'm not wandering in the desert by myself.
1) the AUTH command is only permitted if someone registers at least one AUTH hook (and the transaction begins with EHLO, obviously);
2) There are several possible AUTH hooks: a) auth-plain b) auth-login c) auth-cram_md5 d) auth-digest_md5 (does this have to be supported?)
so that multiple handlers can be registered for any/all.
3) The auth-plain and auth-login share common protocol code in Qpsmtpd and the hook has to provide only an authentication routine.
4) The auth-cram_md5 (and I guess the digest_md5) hook has to handle the entire transaction (since each provider may want to use a custon ticket).
The things that I am having a little difficulty wrapping my head around:
A) Ideally, there would be a single ehlo hook which adds all of the registered AUTH methods in the transaction capabilities array; that should live in the Qpsmtpd::Auth module, but I'm having some problem coming up with a good way to do that.
B) It would be nice if the plugin could advertise a capabilities function of it's own, so the AUTH routine could interrogate to see what methods were available. For example, I could permit PLAIN or LOGIN over SSL or from internal network addresses, but require CRAM-MD5 or DIGEST-MD5 for all others. I'm considering creating a register->hook() function which takes two functions:
i) a callback for checking capabilities
ii) a normal hook function for actually performing the AUTHI'm not going to be able to work on this again until next week, so feel free to discuss amongst yourselves until then... ;~)
John
John
