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 10:35:15 GMT
The relay-denied message should either bounce back to the sender or to the
postmaster, instead of saving it to a mail store.  Otherwise the mail can be
lost.

(Even if mail is not lost, neither option is good enogh, they cause unwanted
traffic. Hopefully this case will not be active at all, because a fast fail
relay check can be used. I don't know the status of the normal fast fail
relay check, but smtp auth with allowed addresses does work as a fast fail
relay test.)

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