I've put up the slides from the Build Easily Extensible Perl Programs (~115KB PDF) talk that you maybe saw the intro page from earlier.
It's mostly code snippets from the mail server project I started years and years ago. (Watch out for more on qpsmtpd later this month or next...)
Over in the Apache HTTPd project they have Summer of Code project to build mod_smtpd, a C smtpd module Apache.
It's a nice cycle. The Qpsmtpd plugin system is based, at least in spirit and some of the conventions, on the Apache module system and since 2002 I had a make a mod_perl smtp handler on the TODO. Last year Will Whittaker proved the mod_perl API was ready by making Apache::SMTP (does that still work? Didn't the mod_perl API change?) and Matt Sergeant wrote us Apache::Qpsmtpd which is now used at apache.org for a couple of million incoming emails a day.
Awesome -- thanks!
We've been pluginizing SpamAssassin for the last couple of releases, and this has some good tips for what remains of the infrastructure work for that.
We implemented our plugin system independently, and have minor differences as a result; for example, we used the can() trick to avoid the use of a register() call right from the outset, but on the other hand, we require that the plugin developer copy and paste the usual perl class boilerplate instead of generating that in an eval as you guys do.
however -- hooks on hooks? ouch! ;)
Justin,
Aren't the hooks on hooks just the logical progression? :-)
I prefer the can() trick too now. Maybe I was following the httpd architecture a bit too closely when I added plugins to qpsmtpd. (Or maybe not, it's working out nicely :-) )
- ask