Someone (with James Server knowledge) probably misunderstood my proposal
to support fastfail operations in Mailet API.
I think that publishing what we are currently defining "handlerapi" in
james server as a standard API is a bad idea.
At the same time I think that Mailet APIs must provide a mean to let
"mailets" (or something else) to better interact with scenarios where we
don't have the full message.
And here are some examples of what I think we should/could add to the api.
Add a mean for Matcher to specify that they don't care of the message
but only of the envelope. This would allow us to use it in systems wher
the envelope does not exists. At the same time add a mean to specify
that the matcher/mailet does not care of the enveloper but only of the
mimemessage (or only of the mime headers): This would be useful to write
a "incoming mail rule engine based on mailet apis" for a java based
email client.
Another improvement to the api would be to give access to the message as
a stream or as a a mime-tree of streams: this would allow to write a
more effective spam tool based on the mailet api. (I'm referring to
something like the SpamAssassin rules and the way SA manage targets of
the checks).
This would give us a lot of potentiality: we could parse the message
once, in the container and let multiple mailets to use the parsed data,
we could avoid to even care of the message if all of our mailets do not
read it, and so on.
Summary:
Adding "Fastfail" to the Mailet APIs means (to me) adding some more
specific object/method/interface to allow processing of partial (or
better "specific") subset of the current Mail object and not publishing
JAMES Server (incomplete) handlerapis that are instead a command pattern
we used to keep our smtpserver modular and more easy to be mantained.
WDYT? Is this something in the middle we could agree upon?
Stefano
