> Basically, matchers and mailets ought to do the best that they
> can. If they
> can handle an exception, they should. If the exception can't be
> reasonably
> handled, the current expectation is for the mailet to set the state to
> ERROR, and to indicate why. Right now that latter isn't happening except
> when LinearProcessor catches an MessagingException thrown from a
> matcher or
> mailet.
>
> You seem to be proposing that the matcher or mailet could throw it back to
> the processor.
Or let it percolate up to the processor.
> [...] I don't have a problem with the idea of adding an
> attribute
> to the processor level to control what to do if a matcher or mailet throws
> an exception. But we should think it through first. I've also thought to
> add a class attribute, so that we can have custom processor types.
>
> You've identified several options:
>
> - matchException=match
> - matchException=nomatch
> - [mailet|match]Exception=<processor>
>
> The default would be the "error" processor. On the surface, it seems
> reasonable, but there are issues to consider. For example, if I were to
> have:
>
> <processor mailetException="specialErrorProcessor">
> <mailet match="All" class="ToProcessor">
> <processor> error </processor>
> </mailet
> </processor>
>
> what do you propose should be done? The case I provided is an explicit
> case, but there are also implicit cases.
We may have a different understanding here:
I'm not willing to control at the <processor name=...> config.xml entry level, but at
the <mailet match=...> level. I'll write an example. I would like to be able to write:
<!-- Check attachment extensions for possible viruses -->
<mailet
match="AttachmentFileNameIs=*.exe,*.com,*.bat,*.pif,*.scr,*.vbs,*.eml,*.avi,*.mp3,*.mpeg,*.shs"
class="Bounce">
<inline>heads</inline>
<attachment>none</attachment>
<passThrough>false</passThrough>
<prefix>[REJECTED]</prefix>
<message>
The security policy of [...] does not allow [...] has been rejected.
</message>
<onMatchException>nomatch</onMatchException>
</mailet>
(Hontvari Jozsef would like instead to have <onMatchException>error</onMatchException>
- the default),
and perhaps in another point, in the same or in other <processor> definition but for
the same matcher and or the same mailet, for whatever reason:
<mailet match="AttachmentFileNameIs=...." class="....">
...
<onMatchException>match</onMatchException>
<onMailetException>spam<onMailetException>
</mailet>
This should be easily done with a few lines of code in LinearProcessor (unless - and
it is very possible) I'm missing something and "making it too easy" :-)
So, if I had this possibility, I would like to have all matchers and mailets catching
and handling only the exceptions that they can locally manage, and throw up (or not
catch) things that they cannot deal with. We should and *could* then avoid having (as
I did in some matchers and mailets - see my recent patch to AttachmentFileNameIs) a
global try/catch just to ensure that mail is not lost.
>
> Another issue to consider: what about where there is an exception
> effecting
> a single recipient, or individual sets of recipients? Do we require
> Matchers and Mailets to build and throw a chain of MessagingException
> objects? Do we need an exception class similar to
> SendFailedException, with
> collections of which ones failed and which ones succeeded? Is
> there another
> way?
As now an uncatched exception percolating up from a matcher, even caused by processing
a single recipient, will have the message go to the error processor, where it will
likely not be forwarded to the final destination, I would as an administrator like the
possibility to control if globally match or not match. As an administrator I know if
the specific <mailet match=... class=...> entry getting the exception is doing a
recipient related matching (like RecipientIs) or a mail related one (like SenderIs or
AttachmentFileNameIs), and I know what to do *globally* to handle the problem.
> For example, Serge pointed out that although it isn't supported,
> the intent
> of the Matcher was to be able to return a collection of collections.
> Perhaps Serge could discuss that again, and we could consider how
> that might
> be used to address exceptions.
>
> Please note that for James v2, we don't want to do anything that
> breaks any
> third party code. For James v3, we would like not to, but could if
> necessary, and by using the class attribute of the processor element, we
> could have a processor compatible with James v2 matchers/mailets if the
> interface conventions changed.
I don't think that what I have in mind would break any compatibility for v2, as the
default would be doing what is being done now. I may be wrong though...
>
> I'm not saying that we should preserve the status quo, but am pointing out
> some of the issues that need to be addressed.
>
> Above all else, we need to keep in mind that the paramount obligation of a
> mail server is reliable delivery. It can try to filter, etc.,
> but it should
> always operate in such fashion as to ensure that mail is not lost.
I totally agree! And I hope that what I have in mind goes in that direction :-)
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
