james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Mailet API was RE: Finer Logging Control for Mailets/Matchers
Date Sun, 09 Jun 2002 19:33:37 GMT
Noel J. Bergman wrote:

>Yes, TCP/IP is a factor, but I'd be more concerned about GC and memory
>issues, not the CPU impact of performing the clone().  
I did not mention clone(), and I'll reassert that it is pointless to 
consider instantiation issues for a heavy TCP/IP using tool.

>However, it is a bit
>of a moot point, since the mail object is largely a carrier for
>javax.mail.internet.MimeMessage, which is not immutable (more on this in a
Perhaps you should consider a clean MimeMessage interface for your 
maillet API.

>>There is _nothing_ wrong with having a small tree of interfaces for
>>Maillet types.
>A "small tree of interfaces" wasn't the issue.  The issue was the loss of
>polymorphism.  Although that isn't always a fatal flaw, the loss of
>polymorphism is never a good thing, and should be avoided without very good
>reason.  That is just good general policy.  In this case, I think that there
>are other ways to achieve the desired goal(s).
>One simple solution would be something like:
>  recipients = matcher.match(matcher.isAllowedChange() ? mail :
>  mailet.service(mailet.isAllowedChange() ? mail : mail.duplicate());
Yup that is good too.  I'd vote for a single multi-purpose method as 
long as the container had pre-profiled the _XML_ declarations for the 

The downside is that it is a smell to return void when the maillet has 
no need for forwaring a mail back into the pipeline.

>(nb: if we care about mail.getState(), we'll have to keep a reference long
>enough to check it).  That would create a copy for any matcher or mailet not
>allowed to affect a change in the content of the object.
>The aforementioned approach says, "we don't know what you might do, and
>can't keep track, so we'll simply give you a copy to damage as you might"
>but it does not address the general problem of malicious components.  For
>example, a malicious mailet involved in industrial espionage could still
>quietly queue up copies.
>This is a general problem, of which the same could be said of rogue Blocks,
>servlets, or any other pluggable component in a pluggable architecture.
I disagree.  The applet model has not been broken ( in terms of security 
) in anything other than a denial of service attack (redirect, opening 
of windows).  Blocks similarly are fine in terms of security, a 
malicious block cannot hack the kernel...

>The Java answer to this general problem appears to be Java Security.  
Yes yes, which Phoenix (and other containers) leverage too.

>wrapper on mutable components, e.g., MimeMessage, could do security checks
>to see if there is permission to affect the desired change.  Likewise, there
>could be a permission check to see if a mailet is permitted to post a new
>message to a processor queue.  Now the administrator can control exactly
>what operations are permitted by a given component.
Yup.... given their XML declarations.... in MAILLET-INF/maillet.xml

- Paul

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message