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: Separating internal errors from addressing errors in config.xml
Date Sun, 08 Jun 2003 21:42:19 GMT
> when I started using James I changed the default
> configuration in this way:

> -error processor is used exclusively for errors (i.e. exceptions catched)
> and nothing else. It forwards these emails to the postmaster, and not to
> the sender. It also stores the mail in the error storage, just to be safe

Same here.  This is my error processor:

      <processor name="error">
         <mailet match="All" class="NotifyPostmaster"/>
         <mailet match="All" class="ToRepository">

There are no references to it in config.xml.  It is used only for internal

I have separate processors for spam, relay-denied, and address-error:

 <processor name="spam">
    <mailet match="All" class="Forward">
    <mailet match="All" class="ToRepository">

 <processor name="relay-denied">
    <mailet match="All" class="ToRepository">

 <processor name="local-address-error">
    <mailet match="All" class="Bounce">
    <mailet match="All" class="ToRepository">

which are invoked as appropriate:

 <mailet match="HostIsLocal" class="ToProcessor">
    <processor> local-address-error </processor>
    <notice>550 - Requested action not taken: no such user here</notice>

 <mailet match="RemoteAddrNotInNetwork=<allowed networks>"
    <processor> relay-denied </processor>
    <notice>550 - Requested action not taken: relaying denied</notice>

> I think the default James configuration should be changed in a similar
> Postmaster must be nitified if unexpected things happen, sender must be
> notified if his mail was not accepted for a specific, known reason.

I agree.  What changes (other than commenting) would you propose to the
above?  I am not proposing it as the right way, just as a stake in the

With respect to exception handling, I don't believe that we need to
complicate the lives of administrators by giving them control over the
outcome of each thrown exception.  Exceptions should be considered in terms
of their semantic meaning.  In many cases, there is appropriate behavior,
and no need to expose it to the administrator.  In many cases, it may not
even make sense to log it, other than at debug level.  Yes, there will be
exceptions that should result in sending a message to the ERROR spool, but
that will probably not be the norm, IMO.

As for Runtime Exceptions, they are a constant source of errors, and should
rarely be used.

	--- Noel

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

View raw message