I don't fully agree. I think that is not correct to close a connection during a DATA session, so I think that there should be NO stage when we received the headers. I also don't like the "remote IP, helo/ehlo host name, recipients, sender, user, whether TLS is enabled or not" stage: this should be modularized but not the matcher/mailet way IMHO.
True, though other servers do it to avoid receiving the whole message. Not ideal though.
IMHO current Matcher/Mailet api are not enough to have REAL, RE-USABLE mailets between different mailet containers: most James mailets currently use and need concepts specific to james, repositories, states, attributes that are not defined by the mailet api.
Repositories are expected to be added, states are already in there (do you have examples of what aren't), attributes are rather app-specific and I wouldn't expect to codify. Maybe some standard ones need to. Got some specifics you think need to be added?
-- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
