I have my WildcardAddress matcher configureed like this:
<!-- Wildcard Address matching -->
<!-- This should replace the 'match="All' class="ToProcessor"' -->
<!-- mailet/matcher pair. The argument is a regular expression -->
<!-- a single group that extracts the real user from the user -->
<!-- portion of the recipient address -->
<mailet match="WildcardAddress=([^-]+)-.+" class="ToProcessor">
<processor> transport </processor>
</mailet>
<!-- Send remaining mails to the transport processor for either
local or remote delivery -->
<!-- mailet match="All" class="ToProcessor">
<processor> transport </processor>
</mailet -->
Thus, I've replaced the 'All' matcher with the 'WildcardAddress' matcher, so
that before the spool sees the messages, the message recipients will have
been "fixed".
The way you describe "forking" a mail in a Mailset (setting the Recipients
on the Mail object) is that I've done in my oither MailSisveMailet. When I
need to add a user-specific header to the message, I have to CLONE the
entire messages, add the header, set the recipient o be that user, send it
-- and then remove that user from the original Mail's recipient list and let
it continue. Granted, because I have to add user-specific headers, it is a
more complex forking operation.
When I read the Javadoc for Matcher when planning to do WildcardAddress, it
said that the Mailet container has the awesome capability to fork messages
for you and all you have to do is return the recipients you wish to receive
that message. So I bent the rules a little bit and made it return the
entire recipient list, but with the recipients who were wildcarding their
MailAddress replaced with their normal MailAddress.
Now I can see how this would be done in a Mailet instead of a Matcher. But,
then, what is the purpose of a Matcher? What is this "awesome forking
capapbility" that the Mailet container has and can only be accessed through
a Matcher.
I'm truly concerned about what you describe about the upcoming API changes.
It sounds like much of what I currently do, and what I hoped to do in the
future, will become impossible.
Regards,
Brian.
-----Original Message-----
From: Vincenzo Gianferrari Pini [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 16, 2003 4:45 AM
To: James Users List
Subject: RE: What to do with my new matcher?
Brian,
Your matcher *is* modifying the Mail, as it is changing the recipients list.
It may just be a matter of personal taste, but IMHO the reason of the
convention that "a matcher should never modify a Mail object" is that a
configuration file becomes harder to read if there are side effects in the
matcher. The meaning of <mailet match="aMatcher=aCondition" class="aMailet">
is "for every recipient (even all) matching the 'aMatcher=aCondition' check
do fork a copy of the message to be processed by 'aMailet'": the *only*
action of the matcher is to fork.
In your case what are you using as a target mailet? I guess you are doing
some kind of "no operation".
Instead of changing the recipients list in your matcher, you can match all
and change such list using MailImpl.setRecipients(Collection) in a mailet,
whose purpose is to do exactly such job, and moreover you would have any
mailet parameter available to customize the behaviour.
This approach though could open the following debate: "what will happen in
V3 for user mailets, as, unlike getRecipients(), setRecipients(Collection)
is not defined in the Mail interface but only in the MailImpl implementor?"
Shouldn't we add it to the Mail interface? More generally, as things stand,
I'm convinced that a large number of user written matchers and mailets *will
not* work under V3 unless they are heavily rewritten, or unless the
interface is made richer. IMHO this, together with the current lack of sync
in CVS between branch_2_1_fcs and head, may kill V3.
Vincenzo
> -----Original Message-----
> From: Brian J. Sayatovic [mailto:[EMAIL PROTECTED]
> Sent: mercoledi 15 ottobre 2003 23.47
> To: 'James Users List'
> Subject: RE: What to do with my new matcher?
>
>
> It doesn't modify the Mail. It leaves it in tact, but the
> Matcher API says
> the Matcher can return the set of recipients that match. So in my case, I
> look at the Mail's recipients, and build an independent list of recipients
> to return.
>
> I build the independent list by either 'filtering' an address with a
> user that matches the pattern and creating an address with the proper
> user, or if it doesn't match, using the address as it was. It does
> this for each recipient in the Mail.
>
> I've configured James to use this as a replacement for the
> All/ToProcessor for the spool processor. Any e-mail that comes in is
> 'matched' and the recipieint list contains all of the recipients the
> original Mail had. The actual Mail headers still contain the original
> To recipients.
>
> I originally considered using a Mailet, but in my last Mailet
> 'forking' a messages seemed quite a pain. When I re-read the
> description of what a Matcher is for this time around, it seemed like
> the perfect fit: (From the
> JavaDoc)
>
> An important feature of the mailet container is the ability
> to fork processing of messages. When a message first arrives
> at the server, it might have multiple recipients specified.
> As a message is passed to a matcher, the matcher might only
> "match" one of the listed recipients. It would then return
> only the matching recipient in the Collection. The mailet
> container should then duplicate the message splitting the
> recipient list across the two messages as per what the
> matcher returned.
>
> If I've gone down the wrong path, I'll gladly backup and go down the
> right one. I'd really like to know because I plans tonight to pair my
> other custom Mailet (spam filter) with a Matcher to handle the
> "forking" part instead of the code I'm using now.
>
> Regards,
> Brian.
>
> -----Original Message-----
> From: Vincenzo Gianferrari Pini
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 7:19 AM
To: James Users List
Subject: RE: What to do with my new matcher?
> Well, I didn't know about that one. I just checked
> http://james.apache.org/provided_matchers_2_1.html and didn't see that
> one listed. Is this new for the next version of James?
>
It has been added in v2.2.0a3.
> Anyways, I'll take a guess that RecipientIsRegex will return only
> those recipients which match a certain regular expression. The
> WildcardAddressMatcher not only uses a regular expression for
> matching, but will replace the 'user' portion of a MailAddress with
> the first RegEx matchign group. This allows me to have
> '[EMAIL PROTECTED]'
> be delivered to '[EMAIL PROTECTED]' when I give it the RegEx in the
> condition of '([^-]+)-' (which is applied to the user portion of the
> MailAddress).
Very good.
But a mailet would be more appropriate, as per convention a matcher should
never modify a Mail object.
Bye,
Vincenzo
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
