Good morning one and all, and it's good to see the Mailet API getting
some attention specifically outside of JAMES. I joined this list after
spotting a blog entry from Danny requesting a discussion.
One of the main reasons I am interested in the MailetAPI is because I
love the abstraction. Being someone who was involved in the early
ServletAPI evolution, this particular interface was a little gem lost in
a sea of rocks.
I won't go into my dislike for JAMES, except to say, I was surprised to
see no one else had any real alternative engines for the Mailet API. So
at SpikeSource, I headed up a project to do just that. We built and
are using, our own Mailet engine. We have open sourced the project and
it's available here:
http://developer.spikesource.com/projects/mailcatcher/
Some docs:
http://alan.blog-city.com/mailcatcher_0_9.htm
It has proved to be very successful internally and we are using it for a
wide range of projects. We here there are plans for it to be bundled in
the next release of an application server.
However the Mailet API itself, while beautiful is missing a number of
significant hooks that we have started to address and will update the
main MailCatcher project soon.
Namely there is no call-back when the MAIL FROM or RCPT TO is invoked by
a remote SMTP server.
The problem with the current implementation of the API is that one must
accept the whole email before you can do any processing as to whether or
not you want it. For spam control, this is completely unacceptable.
You want to nuke the connection ASAP and only spend the resources to
accept an email you really want. To that end we've added a new
interface that deals with this.
So I am looking forward to being part of this discussion and promoting
the use of the Mailet API to hopefully the point where other vendors and
developers want to start supporting it also.
After all - isn't email still the killer app?
--
Alan Williamson, CTO Blog-City Ltd
w: http://www.blog-city.com/
b: http://alan.blog-city.com/