Just thinking out loud here, but how about this for an interface to
generically provide hooks to new SMTP extensions (as pseudocode):
sub register_extension {
my ($COMMAND, &capability, &command, $pre, $post) = @_;
....
}
This would work like this (using AUTH as an example):
- $COMMAND would be the SMTP extension command (AUTH)
- &capability would be a coderef to a function that would return what
keyword should be added to the @capabilities advertised by EHLO (may
return undef, e.g. only provide AUTH if TLS)
- &command would be a coderef to the sub that would actually handle
the $COMMAND (e.g. the current contents of Qpsmtpd::SMTP::auth)
- $pre and $post are optional logicals; if defined, then a
(pre|post)_$COMMAND hook would be auto generated (there is no point in
having a pre_auth hook, but a post_auth might be useful for something).
For implementation purposes, I propose that the &command be inserted
directly into the Qpsmtpd::SMTP namespace and the commands hash, so that
it will be immediately effective. The @capabilities will have to be
autogenerated every time EHLO is called, but that should be at most
twice per message (if TLS is in force).
This should be able to cover everything that AUTH can do in the core now
and be able to handle TLS as well.
An alternative implementation would be to split all of the existing SMTP
commands out into independent Qpsmtpd::SMTP::{cmd} namespaces and use
one of the autoload class modules (Module::Pluggable???) to insert the
commands automatically. Qpsmtpd::Auth would then be renamed to
Qpsmtpd::SMTP::Auth.
Comments?
John
