james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hontvari Jozsef" <hontva...@solware.com>
Subject Re: Separating internal errors from addressing errors in config.xml
Date Thu, 12 Jun 2003 09:34:12 GMT
> What changes (other than commenting) would you propose to the
> above?

(Although this is a kind of comment) I think it is useful to keep a
_commented out_ notifyPostmaster mailet entry in the different bounce
processors. That makes checking of a new installation easier, after
migrating from a different mail server software. The admin may want to
uncomment them for a few days.

----- Original Message -----
From: "Noel J. Bergman" <noel@devtech.com>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Sunday, June 08, 2003 11:42 PM
Subject: RE: Separating internal errors from addressing errors in config.xml


> > 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">
>             <repositoryPath>file://var/mail/error/</repositoryPath>
>          </mailet>
>       </processor>
>
> There are no references to it in config.xml.  It is used only for internal
> errors.
>
> I have separate processors for spam, relay-denied, and address-error:
>
>  <processor name="spam">
>     <mailet match="All" class="Forward">
>        <forwardto>uce@ftc.gov</forwardto>
>     </mailet>
>     <mailet match="All" class="ToRepository">
>        <repositoryPath>file://var/mail/spam/</repositoryPath>
>     </mailet>
>  </processor>
>
>  <processor name="relay-denied">
>     <mailet match="All" class="ToRepository">
>        <repositoryPath>file://var/mail/relay-denied/</repositoryPath>
>     </mailet>
>  </processor>
>
>  <processor name="local-address-error">
>     <mailet match="All" class="Bounce">
>        <attachment>none</attachment>
>     </mailet>
>     <mailet match="All" class="ToRepository">
>        <repositoryPath>file://var/mail/address-error/</repositoryPath>
>     </mailet>
>  </processor>
>
> 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>
>
>  <mailet match="RemoteAddrNotInNetwork=<allowed networks>"
>          class="ToProcessor">
>     <processor> relay-denied </processor>
>     <notice>550 - Requested action not taken: relaying denied</notice>
>  </mailet>
>
> > I think the default James configuration should be changed in a similar
> way.
> > 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
> ground.
>
> 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
>



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


Mime
View raw message