Re: I18N of mailet parameters?

[Hontvari Jozsef]

it would be useful, but what language header do you think about? Is this in
a new RFC (new for me, at least :-) ) or is it an internal convention?


- Original Message - 
From: "Jim Janson" <[EMAIL PROTECTED]>
To: "James Developers List" <[EMAIL PROTECTED]>
Sent: Friday, June 27, 2003 5:22 PM
Subject: I18N of mailet parameters?


> Hi,
>
> I've been playing around with the new Bounce mailet
> in 2.2a7 and it's working great.  Thanks!  One thing I've
> "noticed" (and this is common to all of the mailets) is parameters
> like "notice" or "prefix" are just plain text that is added to the
> mail message.  Works great if we all speak the same language but
> not so good if the server is handling users with different languages.
>
> One thought was to add a resource bundle name and key names
> as parameters to the mailets.  So, there would be ,
> , , etc.  The mailets would then look up
> the keys in the specified bundle using the language in the header of the
> mail message.  If no language was specified, the default bundle
> is used.  If the bundle or key can't be found, the existing notice
> or prefix parameter text is used.
>
> What do you think?  Would this functionality be useful?  What
> are the problems with it?
>
> Thanks,
>
> Jim
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Regarding attachment

[Sundaranathan S]

Hi Noel J. Bergman,


"Noel J. Bergman" wrote:

> > So please can anyone let me know if there is any possible
> > way to attach a file to the mails outgoing from james server.
>
> There isn't a standard mailet for doing so, but it would be fairly
> straightforward to do.  Are you saying that you need something like:
>
>   
> path-to-file
> [mime-type]
> [subject]
>   

How do i go about for doing as per your suggestion above. Can you
please help me out.

thanks,
-Sundaranathan
SIP Technologies & Exports Ltd.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [james-dev] Prefix?

[Noel J. Bergman]

> > Would it be possible to add the list prefix in the title
> > for all the James lists?

> I don't think EZMLM allows subject rewriting... Sorry.

Personally, I like not having those prefixes.  I filter by envelope,
instead.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [james-dev] Prefix?

[Pier Fumagalli]

On 28/6/03 1:36, "Fred Janon" <[EMAIL PROTECTED]> wrote:

> Would it be possible to add the list prefix in the title for all the James
> lists?

I don't think EZMLM allows subject rewriting... Sorry.
One more reason to use James, maybe? :-) :-) :-)

Pier


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[james-dev] Prefix?

[Fred Janon]

Would it be possible to add the list prefix in the title for all the James
lists?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: WORA Considered Evil ;-)

[Noel J. Bergman]

> I'm sure that everyone is in favour of hardening James as much as
possible.
> Its just that we should approach it from a Java perspective, not a C on
> Unix one. The issues are different.

Not so much.  We seem to all be in agreement except on the specific case of
how many JVMs per machine, and why.  We can discuss that in more detail on
james-dev@, and take Community@ off the distribution.  But we should keep
Pier on the list (and add Stefano?) for this discussion.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: WORA Considered Evil ;-)

[Noel J. Bergman]

> > The internals of James models the desired architecture.  The issue
> > concerning you is that the current implementation does it in a single
> > process.  That is at least partially addressable with no change to the
> > architecture, minimal (if any) change to the implementation, and some
> > changes to configuration files.

> I don't see why you couldn't run multiple instances of James each only
> configured to provide one service (SMTP, SPOOL, POP etc) as it stands
> using shared repositories.

Exactly.

> I think it is probably just a configuration excercise (nightmare?).

Pretty much.  :-)  I think might best be a tweak to the spooler, since it
would no longer be getting a notify() from the SMTP handler.  And both James
(the class) and dnsserver would be shared, since they provide services to
all.

> The problem is probably as simple as working out how to define more than
> one $PHOENIX_HOME for start/stop scripts

I admit that doing that is not my highest priority right now.  We've got a
lot of nice new contributions that need to be merged.  But Stefano and Pier
have raised excellent points, which should be addressed.  If anything, they
validate James' architecture.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: WORA Considered Evil ;-)

[Steve Brewin]

Noel,

I'm sure that everyone is in favour of hardening James as much as possible.
Its just that we should approach it from a Java perspective, not a C on Unix
one. The issues are different.

> Frankly, I don't want to run anything at root that can avoid
> it.  That is
> just good practice.

Sure, and you don't have to. Hey, we routinely run BEA WebLogic in
distributed cluster of 20 big Sun/Solaris servers under ids. with just the
required privileges rather than root and just the one JVM per machine, no
problem. There are much larger similar configurations around. There is a big
J2EE app. server base out there that has had to face these issues and
resolve them. They have, so we can.

> Consider Vincenzo's anti-spam matcher.  Would you want that
> to run as root?

No, and there is no need to as explained above. Then I wouldn't want it to
run with the same privileges as James or a James component either. It would
be good to be able to define the launch environment for an executable, which
is where most of the vulnerabilities occur. To be fair, I believe that
Vincenzo has only looked at this from the Win32 perspective and doesn't have
the options available on a Unix platform.

> > There is no need to distribute James' components over
> multiple JVMs to
> > enhance security or robustness.
>
> I disagree as a technical matter.

Such as? I can tell you in advance that my response will be that if a
problem exists it should be fixed at source so that it works within a single
JVM and then scales. Otherwise we are temporarily circumventing the problem
and someday we will hit it again in a distributed solution and ultimately
will have to fix it much more expensively. Been there.

> I can give you plenty of good reasons for why you want the
> ability to run
> the mailet pipeline at privileges other than root:

I think we are agreed that we don't want to run at root and hopefully I have
shown that you don't need to. But the following is really useful in
explaining why we don't want to and what we might want to distribute for
performance reasons.
>
>  - the chance of a JVM exploit.
>  - potential exploits via native code in
>a JDBC driver.
>  - the use of native code in matchers/mailets,
>e.g., the anti-virus matcher.
>---
>  - the use of third party matchers/mailets.
>  - the use of user-defined scripting matchers/mailets
>  - support for SOAP
>  - one pipeline being extra busy or big
>performing lots of processing and/or
>handling large messages, should not
>deny service to other users.
>
I remain unconvinced that all of the issues are potential security risks,
but as I tried to say in an earlier posting, its a matter of trust. We
should certainly make James sufficiently configurable that it can be
integrated into trusted practises wherever feasible, whether that trust is
well placed or not. Conversely, James should be immune as possible from
vulnerabilities exposed by malconfiguration.

> Next, consider the dynamic reconfiguration issue, which
> thread I have no had
> time to respond to over the past couple of days

Noel, I'll respond to this in the Dynamic Reconfiguration thread, but in
short we're in agreement, you are echoing my thoughts here.

-- Steve


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: WORA Considered Evil ;-)

[Noel J. Bergman]

Steve and Kenny,

There is a balance.  Not all of Pier's issues may apply, but many of the
important ones do.

Frankly, I don't want to run anything at root that can avoid it.  That is
just good practice.

Consider Vincenzo's anti-spam matcher.  Would you want that to run as root?
I am not convinced that an exploit cannot be written that would cause the
commercial, native code, virus scanner to have a buffer overflow causing it
to execute code embedded in a carefully crafted message.  Can you prove
otherwise?  How big a bet would you be willing to place?  Because that is
the core of decision theory: what are you willing to risk on your choice?

> There is no need to distribute James' components over multiple JVMs to
> enhance security or robustness.

I disagree as a technical matter.  As a practical matter, it depends upon
one's configuration and comfort level.  Clearly most users experience levels
of both security and robustness with James that meet their requirements.

> The paranoia comes from what's called a buffer overflow
> exploit.

> Java however doesn't suffer from this kind of attack

As a matter of fact, there was one involving the native compression code.

I agree that Java is safer than C/C++, but that does not diminish the point.
I can give you plenty of good reasons for why you want the ability to run
the mailet pipeline at privileges other than root:

 - the chance of a JVM exploit.
 - potential exploits via native code in
   a JDBC driver.
 - the use of native code in matchers/mailets,
   e.g., the anti-virus matcher.
   ---
 - the use of third party matchers/mailets.
 - the use of user-defined scripting matchers/mailets
 - support for SOAP
 - one pipeline being extra busy or big
   performing lots of processing and/or
   handling large messages, should not
   deny service to other users.

None of the items below the bar are related to native code exploits.  A
single JVM is not secure when you start taking into account such things as
SOAP, user-defined scripts, etc.  Would you run Tomcat as root, and allow
users to install whatever servlets they want at root privilege?

For most users, the risk involved may be effectively non-existent, but the
more flexible a system becomes, the more the system must be architected to
prevent exploits due to an oversight failure.  For Tomcat, I make sure that
each virtual host's JVM(s) run(s) with the access right's of the host's
owner.  If I have mail applications for multiple hosts, I also want to
ensure separation, security, and privacy.

Next, consider the dynamic reconfiguration issue, which thread I have no had
time to respond to over the past couple of days.  The key issue there is
that to reconfigure the pipeline, I should not have to impact the other
services.  What you might do for a graceful reconfig is to put the pipeline
into a mode where it will process all messages EXCEPT for those in the root
spool.  That lets you flush out the current pipeline, while allowing the
SMTP server to continue spooling messages.  Then I can gracefully restart
the pipeline processor without any impact on SMTP, POP3, NNTP or other
service.

We've already had the plan for a distributed pipeline cluster, so I don't
see any reason to be arguing the point.  If you look at Pier's message, you
should see GOOD things, not bad.  The architecture is basically exactly what
he wants.

> Using multiple VMs forces the use of some kind of remote interface.

We already have one: the spooler and message stores.  Separation would occur
where natural divisions exist.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: I18N of mailet parameters?

[Danny Angus]

> >We could use either resource bundles or XML resources.  See the new
> >XMLResources.java, which is a generalization of SQLResources.java, which
> >came from some other source whose history is lost (Darrell may remember).

SQLResources was one of the first discussions I was involved with, abstracting SQL 
from hardcoded into the java into a seperate resource which could be added to by SQL 
savvy non-java people. Seems like this is a problem in the same domain.

One thing to be aware of is that some parts of mail messages are not localizable, but 
*MUST* be US ASCII.

d.

RE: Dynamic Reconfiguration

[Steve Brewin]

Noel,

> > Avalon frameworks manage the core tasks and should ideally
> manage the
> > reconfiguration of those tasks. Achieving this means that all Avalon
> > components benefit from these advances.
>
> Ideally, yes.  This is something that we should bring up with
> Avalon, not
> just here.  They should provide the core facilities, and we
> should know how
> to use them.

Yep!

> > The configuration file, config.xml, is essentially a
> persistent store for
> > the configuration parameters. As it is XML based we may as
> well go with
> it.
> > We may well want to expose the parsed parameters as Java
> objects through
> > some kind of interface.
>
> You mean, other than the existing ones?

Probably an extension of the current Configuration interface. One tactic is
to parse the config into Java objects at startup (as now). During runtime
make configuration changes by updating the parsed objects (not supported by
the current Configuration inteface) notifying participants that they have
changed. At shutdown, write the current state of the parsed objects back to
the config (similarly not yet supported).
>
> > Probably James would use the Java objects as its
> configuration source
> > and perist any changes to the Java objects by updating config.xml.
>
> Avalon provides the configuration interfaces, and should be
> responsible for
> the core support.  However, I would not want to see normal
> components able
> to effect configuratin changes.  The JMX support should be
> able to do so.

Hmmm. What's a "normal component"? What makes JMX a special case? Once we
expose a public interface for making configuration changes we have no
control over what uses it. This is as it should be. These interfaces should
be secure such that only an authorised entity can make configuration
changes, be it via JMX or another avenue. I'm real keen on JMX but don't
want to exclude the possibility of a non-JMX solution such as a simple
terminal or GUI interface.
>
> Basically, I agree with your thoughts.  I am simply
> emphasizing that the
> core integration of (re-)configuration and JMX should be part
> of Avalon.

I totally agree. Ideally James components should see reconfiguration events
triggered by Avalon and act accordingly. Avalon should be in control.

> If
> we do it here, for example if that is something you want to
> undertake, it
> really should be done by contributing to Avalon.

Currently I am just trying to promote a discussion of what needs to be done,
and how, for James to be able to dynamically reconfigure. Personally, I
expect that the eventual conclusion will be that much of the responsibility
will fall on Avalon and James will respond to triggers. But that is just my
opinion.

I'll give it a week, then try and summarise everyones thoughts (on the
Wiki?). See where it goes from there. I know where I'm going at that point -
sailing!

-- Steve


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: WORA Considered Evil ;-)

[Danny Angus]

> The internals of James models the desired architecture.  The issue
> concerning you is that the current implementation does it in a single
> process.  That is at least partially addressable with no change to the
> architecture, minimal (if any) change to the implementation, and some
> changes to configuration files.

I don't see why you couldn't run multiple instances of James each only configured to 
provide one service (SMTP, SPOOL, POP etc) as it stands using shared repositories. I 
think it is probably just a configuration excercise (nightmare?).

The problem is probably as simple as working out how to define more than one 
$PHOENIX_HOME for start/stop scripts

d.

Re: I18N of mailet parameters?

[Jim Janson]

Noel,

We could use either resource bundles or XML resources.  See the new
XMLResources.java, which is a generalization of SQLResources.java, which
came from some other source whose history is lost (Darrell may remember).
Mark Imel's new list server is the first code to use it (other than my
XMLTest mailet).  I will be posting that up later today; this weekend at the
latest.
There is code in XMLResources for doing symbolic parameter substitution,
which might be good to pull out into a general utility class, since it can
be useful other than in the context of an XML resource file.
Is this something that you would like to contribute to?

Sure, I'll give it a go.  I haven't looked at any of the new XML resource
code yet so I'll start there.
If you have any other pointers, I'd appreciate it.

Thanks.

Jim



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Dynamic Reconfiguration

[Noel J. Bergman]

> Avalon frameworks manage the core tasks and should ideally manage the
> reconfiguration of those tasks. Achieving this means that all Avalon
> components benefit from these advances.

Ideally, yes.  This is something that we should bring up with Avalon, not
just here.  They should provide the core facilities, and we should know how
to use them.

> The configuration file, config.xml, is essentially a persistent store for
> the configuration parameters. As it is XML based we may as well go with
it.
> We may well want to expose the parsed parameters as Java objects through
> some kind of interface.

You mean, other than the existing ones?

> Probably James would use the Java objects as its configuration source
> and perist any changes to the Java objects by updating config.xml.

Avalon provides the configuration interfaces, and should be responsible for
the core support.  However, I would not want to see normal components able
to effect configuratin changes.  The JMX support should be able to do so.

Basically, I agree with your thoughts.  I am simply emphasizing that the
core integration of (re-)configuration and JMX should be part of Avalon.  If
we do it here, for example if that is something you want to undertake, it
really should be done by contributing to Avalon.

--- Noel

cc: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: WORA Considered Evil ;-)

[Noel J. Bergman]

> I was raising concerns that *real* sysadms have. I don't know any sysadm
> who, free to choose his server operating system, would choose windosh.

I personally don't consider Windows to be robust and secure enough as a
server operating system.  But that is far from a universal view, and I don't
feel compelled to enforce my personal opinion by abandoning over 40% of my
community.  Is httpd deciding to drop support for Windows (rhetorical)?

> If you want James to be good-enough for the ASF (even if it doesn't get
> into production), forget your windows user base and target the real
> heavy duty servers.

I don't believe it necessary to architect or implement something that
excludes Windows in order to deliver a suitable product.

The internals of James models the desired architecture.  The issue
concerning you is that the current implementation does it in a single
process.  That is at least partially addressable with no change to the
architecture, minimal (if any) change to the implementation, and some
changes to configuration files.  Providing that configuration as an
alternative to a single JVM is certainly something we can take a close look
at offering.  There are good reasons for allowing the mail administrator to
choose (easy of use and reduced memory consumption vs robustness and
flexibility).

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: WORA Considered Evil ;-)

[Steve Brewin]

Rather than picking off Piers points one by one I'ld say that the "rock
solid arguments *not* to use JAMES as a MTA" do not hold in a Java
environment and therefore do not apply to James.

Pier trusts the setup he describes because it solves the problems
encountered in a C on Unix world. These are not the same problems
encountered by James, or any other Java application running on a JVM with an
appropriate security policy, whatever the OS.

There is no need to distibute James' components over multiple JVMs to
enhance security or robustness.

Security isn't an issue in the same way as it is with C. With C I can
happily play around with any memory location in my address space but the JVM
ensures that objects are bound to and do not break their contracts. A
greater level of isolation is provided within a JVM than is provided by
running separate processes in Unix.

A thread going down within the JVM does not take the JVM down with it unless
an unhandled Error or Exception is thrown. If the Error/Exception handling
is correct, the JVM will only terminate when there is no point in
continuing, generally due to misconfiguration or resource depletion. These
are issues that would have the same consequence in a multiple JVM, same
machine environment.

Using multiple VMs forces the use of some kind of remote interface. The poor
performance of remote interfaces is well known and contributed much to the
poor performance of EJBs until local interfaces were introduced. This is not
a road down which to travel without serious cause.

In the early days of Java there was a good reason to run multiple JVMs.
Performance when garbage collecting large heaps was very poor. Having
several smaller heaps by way of multiple JVMs was a workaround. Current JVMs
are much much better, so its no longer a good trade off against the cost of
remote interfaces.

These days, the only reason for multiple JVMs is to distribute across
multiple machines for scalability and robustness (if a machine goes down or
runs out of resources, the app. continues to run on the others).

And finally, as a general observation. Modern JVMs make extremely good use
of the native threading libraries at their disposal. They can be configured
to exploit them as required, look at Sun's latest for instance. And if you
want JVM fast start (pre-loaded, ready to go JVMs) its on its way.

-- Steve


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: I18N of mailet parameters?

[Noel J. Bergman]

Jim,

> One thing I've "noticed" (and this is common to all of the mailets)
> is parameters like "notice" or "prefix" are just plain text that is
> added to the mail message.

> One thought was to add a resource bundle name and key names
> as parameters to the mailets.

We could use either resource bundles or XML resources.  See the new
XMLResources.java, which is a generalization of SQLResources.java, which
came from some other source whose history is lost (Darrell may remember).

Mark Imel's new list server is the first code to use it (other than my
XMLTest mailet).  I will be posting that up later today; this weekend at the
latest.

There is code in XMLResources for doing symbolic parameter substitution,
which might be good to pull out into a general utility class, since it can
be useful other than in the context of an XML resource file.

Is this something that you would like to contribute to?

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WORA Considered Evil ;-)

[Kenny Smith]

Pier mentioned this point repeatedly, asserting that security can be 
gained by running the various pieces of the MTA under different users' 
privileges.  Since I also lack sysadmin experience, I wonder if someone 
could tell me the motivation for this precaution. Historically, what 
went wrong that caused sysadmins to prefer running separate pieces of an 
MTA under separate users' privileges?
You are correct, it is a holdover from dealing with so many applications 
written in C. The paranoia comes from what's called a buffer overflow 
exploit. In C, if you write special data into memory that goes beyond 
the end of an allocated memory chunk, then the attacker can gain access 
to a shell prompt running as the owner of the process. This means, if 
you were running it as root, the attacker now has root access. However, 
if you segment the whole setup into multiple pieces with multiple users 
and one of the pieces suffers from a buffer overflow exploit, then the 
attacker only gains access to a very small piece of the system. It's all 
about minimizing the potential damage should a programming bug be found.

Java however doesn't suffer from this kind of attack because the JVM 
does bounds checking on your memory, so you can't overflow a buffer.

Kenny Smith
JournalScape.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

I18N of mailet parameters?

[Jim Janson]

Hi,

I've been playing around with the new Bounce mailet
in 2.2a7 and it's working great.  Thanks!  One thing I've
"noticed" (and this is common to all of the mailets) is parameters
like "notice" or "prefix" are just plain text that is added to the
mail message.  Works great if we all speak the same language but
not so good if the server is handling users with different languages.
One thought was to add a resource bundle name and key names
as parameters to the mailets.  So, there would be ,
, , etc.  The mailets would then look up
the keys in the specified bundle using the language in the header of the
mail message.  If no language was specified, the default bundle
is used.  If the bundle or key can't be found, the existing notice
or prefix parameter text is used.
What do you think?  Would this functionality be useful?  What
are the problems with it?
Thanks,

Jim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-james/src/java/org/apache/james/transport/mailets Resend.java AbstractNotify.java AbstractRedirect.java Bounce.java Forward.java NotifyPostmaster.java NotifySender.java Redirect.java

[vincenzo]

vincenzo2003/06/27 07:34:38

  Modified:src/java/org/apache/james/transport/mailets Tag:
branch_2_1_fcs AbstractNotify.java
AbstractRedirect.java Bounce.java Forward.java
NotifyPostmaster.java NotifySender.java
Redirect.java
  Added:   src/java/org/apache/james/transport/mailets Tag:
branch_2_1_fcs Resend.java
  Log:
  1) Moved all default init parameters management up to AbstractRedirect, and changed 
consequently all the subclasses.
  2) Added new Resend mailet that can replace Redirect having a consistent default 
behaviour and adds support for new  parameter.
  3) Added support of null that deletes the "ReplyTo:" header from 
the resent message.
  4) Javadoc changed accordingly and further cleaned.
  5) During initialization all the classes check that only the allowed init parameters 
are used, throwing an exception if any unknown are found.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.7   +44 -17
jakarta-james/src/java/org/apache/james/transport/mailets/AbstractNotify.java
  
  Index: AbstractNotify.java
  ===
  RCS file: 
/home/cvs/jakarta-james/src/java/org/apache/james/transport/mailets/AbstractNotify.java,v
  retrieving revision 1.1.2.6
  retrieving revision 1.1.2.7
  diff -u -r1.1.2.6 -r1.1.2.7
  --- AbstractNotify.java   25 Jun 2003 22:02:31 -  1.1.2.6
  +++ AbstractNotify.java   27 Jun 2003 14:34:37 -  1.1.2.7
  @@ -102,18 +102,19 @@
* Sample configuration common to all notification mailet subclasses:
* 
* 
  - *   an address or postmaster or sender or unaltered, 
default=postmaster
  - *   true or false, 
default=false
  - *   notice attached to the message (optional)
  + *   an address or postmaster or sender or unaltered, 
default=postmaster
  + *   true or false, default=false
  + *   notice attached to the original message text 
(optional)
*   optional subject prefix prepended to the original 
message
*   see [EMAIL PROTECTED] Redirect}, 
default=none
*   see [EMAIL PROTECTED] Redirect}, 
default=message
*   true or false, default=true
*   true or false, 
default=true
  + *   true or false, default=false
* 
* 
  - * message and attachError can be used instead of
  - * notice and  and attachStackTrace.
  + * notice, senderAddress and attachStackTrace can be used 
instead of
  + * message, sender and attachError; such names are kept for 
backward compatibility.
*
* @version CVS $Revision$ $Date$
* @since 2.2.0
  @@ -158,7 +159,8 @@
   }
   
   /**
  - * @return the notice init parameter, or the message 
init parameter if missing,
  + * @return the notice init parameter,
  + * or the message init parameter if missing,
* or a default string if both are missing
*/
   protected String getMessage() {
  @@ -238,27 +240,52 @@
   return sout.toString();
   }
   
  +// All subclasses of AbstractNotify are expected to establish their own 
recipients
  +abstract protected Collection getRecipients() throws MessagingException;
  +
  +/**
  + * @return null
  + */
  +protected InternetAddress[] getTo() throws MessagingException {
  +return null;
  +}
  +
  +/**
  + * @return SpecialAddress.NULL, that will remove the "ReplyTo:" 
header
  + */
  +protected MailAddress getReplyTo() throws MessagingException {
  +return SpecialAddress.NULL;
  +}
  +
   /**
  - * @return the value of the sendingAddress init parameter if not 
null,
  - * the postmaster address otherwise
  + * @return null
  + */
  +protected MailAddress getReturnPath() throws MessagingException {
  +return null;
  +}
  +
  +/**
  + * @return the value of the sendingAddress init parameter,
  + * or the value of the sender init parameter if missing,
  + * or the postmaster address if both are missing
*/
   protected MailAddress getSender() throws MessagingException {
   if (getInitParameter("sendingAddress") == null) {
  -return getMailetContext().getPostmaster();
  +if (getInitParameter("sender") == null) {
  +return getMailetContext().getPostmaster();
  +} else {
  +return new MailAddress(getInitParameter("sender"));
  +}
   } else {
   return new MailAddress(getInitParameter("sending

cvs commit: jakarta-james/src/java/org/apache/james/transport/mailets AbstractNotify.java AbstractRedirect.java Bounce.java Forward.java NotifyPostmaster.java NotifySender.java Redirect.java

[vincenzo]

vincenzo2003/06/27 07:25:47

  Modified:src/java/org/apache/james/transport/mailets
AbstractNotify.java AbstractRedirect.java
Bounce.java Forward.java NotifyPostmaster.java
NotifySender.java Redirect.java
  Log:
  1) Moved all default init parameters management up to AbstractRedirect, and changed 
consequently all the subclasses.
  2) Added new Resend mailet that can replace Redirect having a consistent default 
behaviour and adds support for new  parameter.
  3) Added support of null that deletes the "ReplyTo:" header from 
the resent message.
  4) Javadoc changed accordingly and further cleaned.
  
  Revision  ChangesPath
  1.7   +44 -17
jakarta-james/src/java/org/apache/james/transport/mailets/AbstractNotify.java
  
  Index: AbstractNotify.java
  ===
  RCS file: 
/home/cvs/jakarta-james/src/java/org/apache/james/transport/mailets/AbstractNotify.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- AbstractNotify.java   25 Jun 2003 22:00:37 -  1.6
  +++ AbstractNotify.java   27 Jun 2003 14:25:46 -  1.7
  @@ -102,18 +102,19 @@
* Sample configuration common to all notification mailet subclasses:
* 
* 
  - *   an address or postmaster or sender or unaltered, 
default=postmaster
  - *   true or false, 
default=false
  - *   notice attached to the message (optional)
  + *   an address or postmaster or sender or unaltered, 
default=postmaster
  + *   true or false, default=false
  + *   notice attached to the original message text 
(optional)
*   optional subject prefix prepended to the original 
message
*   see [EMAIL PROTECTED] Redirect}, 
default=none
*   see [EMAIL PROTECTED] Redirect}, 
default=message
*   true or false, default=true
*   true or false, 
default=true
  + *   true or false, default=false
* 
* 
  - * message and attachError can be used instead of
  - * notice and  and attachStackTrace.
  + * notice, senderAddress and attachStackTrace can be used 
instead of
  + * message, sender and attachError; such names are kept for 
backward compatibility.
*
* @version CVS $Revision$ $Date$
* @since 2.2.0
  @@ -158,7 +159,8 @@
   }
   
   /**
  - * @return the notice init parameter, or the message 
init parameter if missing,
  + * @return the notice init parameter,
  + * or the message init parameter if missing,
* or a default string if both are missing
*/
   protected String getMessage() {
  @@ -238,27 +240,52 @@
   return sout.toString();
   }
   
  +// All subclasses of AbstractNotify are expected to establish their own 
recipients
  +abstract protected Collection getRecipients() throws MessagingException;
  +
  +/**
  + * @return null
  + */
  +protected InternetAddress[] getTo() throws MessagingException {
  +return null;
  +}
  +
  +/**
  + * @return SpecialAddress.NULL, that will remove the "ReplyTo:" 
header
  + */
  +protected MailAddress getReplyTo() throws MessagingException {
  +return SpecialAddress.NULL;
  +}
  +
   /**
  - * @return the value of the sendingAddress init parameter if not 
null,
  - * the postmaster address otherwise
  + * @return null
  + */
  +protected MailAddress getReturnPath() throws MessagingException {
  +return null;
  +}
  +
  +/**
  + * @return the value of the sendingAddress init parameter,
  + * or the value of the sender init parameter if missing,
  + * or the postmaster address if both are missing
*/
   protected MailAddress getSender() throws MessagingException {
   if (getInitParameter("sendingAddress") == null) {
  -return getMailetContext().getPostmaster();
  +if (getInitParameter("sender") == null) {
  +return getMailetContext().getPostmaster();
  +} else {
  +return new MailAddress(getInitParameter("sender"));
  +}
   } else {
   return new MailAddress(getInitParameter("sendingAddress"));
   }
   }
   
   /**
  - * @return the prefix init parameter or an empty string if missing
  + * @return null
*/
  -protected String getSubjectPrefix() throws MessagingException {
  -if(getInitParameter("prefix") == null) {
  -return "";
  -} else {
  -return getInitParameter("prefix");
  -}
  +protected

cvs commit: jakarta-james/src/java/org/apache/james/transport/mailets Resend.java

[vincenzo]

vincenzo2003/06/27 07:15:13

  Added:   src/java/org/apache/james/transport/mailets Resend.java
  Log:
  .
  
  Revision  ChangesPath
  1.1  
jakarta-james/src/java/org/apache/james/transport/mailets/Resend.java
  
  Index: Resend.java
  ===
  /* 
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 2000-2003 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution,
   *if any, must include the following acknowledgment:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowledgment may appear in the software itself,
   *if and wherever such third-party acknowledgments normally appear.
   *
   * 4. The names "Apache", "Jakarta", "JAMES" and "Apache Software Foundation"
   *must not be used to endorse or promote products derived from this
   *software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache",
   *nor may "Apache" appear in their name, without prior written
   *permission of the Apache Software Foundation.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   * Portions of this software are based upon public domain software
   * originally written at the National Center for Supercomputing Applications,
   * University of Illinois, Urbana-Champaign.
   */
  
  package org.apache.james.transport.mailets;
  
  import java.io.PrintWriter;
  import java.io.StringWriter;
  
  import java.util.Collection;
  import java.util.Date;
  import java.util.Enumeration;
  import java.util.HashSet;
  import java.util.Iterator;
  import java.util.Locale;
  import java.util.StringTokenizer;
  import java.util.ArrayList;
  
  
  import javax.mail.Message;
  import javax.mail.MessagingException;
  import javax.mail.Session;
  import javax.mail.internet.InternetAddress;
  import javax.mail.internet.MimeBodyPart;
  import javax.mail.internet.MimeMessage;
  import javax.mail.internet.MimeMultipart;
  
  import org.apache.james.core.MailImpl;
  
  import org.apache.mailet.GenericMailet;
  import org.apache.mailet.Mail;
  import org.apache.mailet.MailAddress;
  
  
  /**
   * A mailet providing configurable redirection services.
   * Can produce listserver, forward and notify behaviour, with the original
   * message intact, attached, appended or left out altogether.
   * Should be used as a replacement to [EMAIL PROTECTED] Redirect}, as defaults are 
more consistent,
   * and has new options available.
   * This built in functionality is controlled by the configuration as laid out 
below.
   * In the table please note that the parameters controlling message headers
   * accept the "unaltered" value, whose meaning is to keep the 
associated
   * header unchanged and, unless stated differently, corresponds to the assumed 
default
   * if the parameter is missing.
   * The configuration parameters are:
   * 
   * 
   * 
   * 
   * A comma delimited list of email addresses for recipients of
   * this message;.
   * It can include constants

Re: WORA Considered Evil ;-)

[Richard O. Hammer]

Pier Fumagalli wrote:
All those components must run ...  (for security) under different user
privileges.
Pier mentioned this point repeatedly, asserting that security can be 
gained by running the various pieces of the MTA under different users' 
privileges.  Since I also lack sysadmin experience, I wonder if 
someone could tell me the motivation for this precaution. 
Historically, what went wrong that caused sysadmins to prefer running 
separate pieces of an MTA under separate users' privileges?

I wonder if that kind of thing, whatever it was that went wrong, could 
happen with Java and James.  Java has a lot of security built in which 
is lacking in C and other languages.

I wonder if a lot of the traditional sysadmin's paranoia comes from 
growing up with Sendmail.  As I understand the history, Sendmail had 
its architectural foundations laid before anyone thought much about 
security.  As such, it helped raise a generation of paranoid sysadmins.

But when you understand a problem it usually suffices to solve the 
problem once, just exactly once.  After you have stepped on a bug, it 
does not always help to step on it again a second, third, ... tenth time.

But of course paranoia evolved into the human psyche for some good 
reason.  Until you have mastered a problem paranoia often pays: do 
anything, do everything.

Rich Hammer
Hillsborough, N.C.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]