Noel i am going to ignore the majority of your email, because in essence
it boils down to your statement here:
The Mailet pipeline deals with messages and routing, and is independent of
protocol. It could not care less how messages are inserted into the spool.
I fully agree with this statement. The key phrase here is "routing".
This isn't about conflating anything, this is about giving the necessary
hooks within the API to intelligently decide on whether or not we wish
to "route" this email any further through the system.
So forget about procotols, forget about where the email is coming from,
it boils down to the simple question:
"Do i want to accept this email?"
Now, ironically enough the Mailet API already answers this question in
the Matcher classes. So I am not sure where your arguments are coming from.
We need to move this processing/decision making further up the chain.
We need to provide developers with the ability to get a peek at the
message as soon as possible.
Yes, the examples you give FetchMail, IMAP (does JAMES even support this
yet?), NNTP (which to be honest with you, anyone using Mailets/JavaMail
to work with an NNTP server is just darn right crazy; there is one
protocol that should never have been in the JavaMail API. We can duke
that one out later!) will all still work. If they do not wish to
override/implement the interface then they don't.
But to say it is outside of the current Mailet API, is wrong IMO. The
Mailet API is for the routing and handling of emails -- all we are
talking about is allowing the developer to make this decision much
faster/earlier.
As for how the container implementation; how the container wants to
handle the non-SMTP cases is up to them. For my own part, I am only
interested in the 99.9999% of cases when emails originate via SMTP.
