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 Sun, 08 Jun 2003 09:06:44 GMT
Yes, 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, in
case the sending to the postmaster also fails. The postmaster must decide
what to do with the letter. E.g. notify the sender that his system is
broken, notify the receiver, fix a bug in james. Until now it was quite easy
for me (the postmaster): all of these letters were useless (virus).

-I created a new bounce processor. It bounces back the message to the sender
(and nobody else), with an error message explaining the reason. The error
message is provided by the mailet which sent the email to the bounce
processor (i.e. the calling ToProcessor mailet has a "notice" configuration
element). This processor is called at several places. It uses the
NotifySender at this moment yet, but it should be replaced by the new bounce
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.

Another subject: Personally I do want to know if an unexpected exception
happens in the mail server. I always feel uncomfortable if unexpected
exceptions are simply swallowed. In the specific case, the
AttachmentFileNameIs mailet and a malformed email, swallowing exceptions and
delivering malformed messages to the original recipient contradicts its
purpose. As the experience shows, malformed letters are exactly those
letters that I would like to filter out (virus).




----- Original Message -----
From: "Vincenzo Gianferrari Pini" <vincenzo.gianferraripini@praxis.it>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Sunday, June 08, 2003 1:38 AM
Subject: RE: Separating internal errors from addressing errors in config.xml


Noel,

in the last hour I was making with myself a very similar consideration.

Today I watched in my production system about five malformed messages,
fortunately spam (today is saturday), that caused an exception in a matcher
(AttachmentFileNameIs) and as a result ended in the error processor, and
finally in the error store, among hundreds of others that are simply
addressing errors: no administrator would ever check them. I did it because
I was "ears up" controlling the behaviour of the changes introduced a couple
of days ago to fight against the new Bugbear virus; the changes were based
on using such matcher bouncing back messages having "dangerous" *.exe
attachments. But those five were lost, and this was a mistake.

The solution I figured out was to "in case of doubt" have the matcher fail
instead of throwing an exception and end in error, so I patched the matcher
accordingly. And I think that in this specific situation it is ok.

I was then elucubrating on which are (or should) be in James the rules to
follow handling exceptions (RuntimeException inclusive), in mailets (to give
as advice to mailet implementors) and everywhere else. And I think that
there is a potential confusion between the meanings of exceptions.

Probably there are very few rules to follow:

1) If the outcome of not catching an exception is having the james go down,
it must be catched somewhere in the chain, unless it is related to
installation/configuration errors during startup. I think that we all agree
on this.

2) If the outcome of not catching an exception is not having a message
delivered to the final recipient, supposing it exists and is valid, I was
going to say: let's catch it "in case of doubt" and have it go to
destination; it is the same attitude of avoiding false positives when
checking for spam. But this wrong: such (hopefully) rare messages should go
to a different error processor, that stores it in a different error store,
and forwards it to the postmaster, not back to the sender.

All this would consist in organizing the configuration and having it
understood by the administrators, but also reviewing the try/catch code in
the mailets and matchers, going in the opposite way of my patch. Perhaps
also have the exception stored with a setErrorMessage(String) and not only
logged, so that it is forwarded by NotifyPostmaster together with the
message.

Vincenzo

> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: sabato 7 giugno 2003 23.30
> To: James-Dev Mailing List
> Subject: Separating internal errors from addressing errors in config.xml
>
>
> James.Mailet: Error while storing mail.
> log-java.lang.RuntimeException: Exception caught while storing mail
> Container: java.sql.SQLException: Communication link failure:
> java.net.SocketException
> -    at
> mailrepository.JDBCMailRepository.store(JDBCMailRepository.java:650)
> -    at James.storeMail(James.java:856)
>  ...
>
> Very rare (the above is the only occurance of it this year), but when this
> happens, the message is sent to the error processor.  That is also where
> address errors are sent.
>
> My suggestion is that we separate server errors and address errors in the
> default configuration.  Address errors are something that you
> might want to
> bounce, but you might not want to bounce the above, since it is something
> that can be fixed locally.
>
> We'd want a Bounce processor to be able to report one as a 5xx,
> the other a
> 4xx, assuming a bounce was configured for either.
>
> --- 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



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