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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
