james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: New Mailet API - Was Re: what competition is doing
Date Tue, 03 May 2005 20:32:40 GMT
Serge Knystautas wrote:

> apache@bago.org wrote:
> > 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.

We have a pretty good model for doing this, as you may recall.  Courtesy of
Alex, if I recall correctly.  A bit of tweaking was agreed upon, but it
would be an in-protocol processor providing a reasonable capability for
fast-fail.


> > 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.

Not true.  Not *most*.  Only a few, and we can add some additional
capabilities to the Mailet API.

Not sure if the user and store interfaces should ever be in that set,
though, since there are entire ranges of mailet containers that don't need
to provide them.  Those are services, which could be discoverable.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message