You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Hontvari Jozsef <ho...@solware.com> on 2003/06/23 22:35:53 UTC
subject prefix mailet or unaltered recipients in Redirect
Because Outlook Express cannot filter messages (spam) based on headers, I
would need a mailet which adds a prefix to the subject. It mustn't do
anything else, e.g. it doesn't change the message id etc.
This functionality is already in the code, in at least two places, in the
Redirect mailet and in the GenericListServ mailet. As I already experienced
this it is not a simple operation, because it has to guess the appropriate
charset.
I guess if there were an "unaltered" option in the recipients parameter of
the redirect mailet then it would make the job. Or maybe a separate mailet
is better. What do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
>
>
> > > Always was. I propose that for undocumented defaults, that we change
> them
> > > to be consistent (as discussed in this thread), and document the
> changes.
>
> > We can't do that. It would break most config.xml files around.
>
> Yes, I know ... <<sigh>> I said as much in an earlier message. Wishful
> thinking in a moment of weakness. I was kind of hoping that no one would
> object, but you are correct to do so.
>
> > I suggest to complete what I'm doing getting a totally back compatible
> > and documented Redirect, and later on we can have a new one [that]
> > behaves as Noel says, and Redirect extends it just changing the
> > defaults to keep the compatibility.
>
> Probably the best thing to do. Redirect used to call itself Resend. We
> could adopt that name for the new mailet if we don't come up with a better
> one.
>
> Would it be reasonable to have AbstractRedirect have the consistent
> defaults, which are then picked up by AbstractNotify, Forward,
> and other new
> subclasses of AbstractRedirect; and have Redirect introduce its
> compatibility values?
I'll do that, plus create a Resend mailet.
In the meantime I've committed a new version of the hierarchy that uses consistently "unaltered" and has javadoc updated to reflect that and showing/explaining all the defaults.
Good night :-O) (yawn)
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > Always was. I propose that for undocumented defaults, that we change
them
> > to be consistent (as discussed in this thread), and document the
changes.
> We can't do that. It would break most config.xml files around.
Yes, I know ... <<sigh>> I said as much in an earlier message. Wishful
thinking in a moment of weakness. I was kind of hoping that no one would
object, but you are correct to do so.
> I suggest to complete what I'm doing getting a totally back compatible
> and documented Redirect, and later on we can have a new one [that]
> behaves as Noel says, and Redirect extends it just changing the
> defaults to keep the compatibility.
Probably the best thing to do. Redirect used to call itself Resend. We
could adopt that name for the new mailet if we don't come up with a better
one.
Would it be reasonable to have AbstractRedirect have the consistent
defaults, which are then picked up by AbstractNotify, Forward, and other new
subclasses of AbstractRedirect; and have Redirect introduce its
compatibility values?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
>
> > > As you already said, Redirect suffers from the need of backward
> compatibility,
> > > that we must guarantee. We could in the future create a new
> mailet, with
> a
> > > different name (which name BTW?) following more consistently the
> conventions.
>
> > This mailet has become a veritable swiss-army knife of confusion. :)
>
> Always was. I propose that for undocumented defaults, that we change them
> to be consistent (as discussed in this thread), and document the changes.
> Doing:
>
> <mailet match="All" class="Redirect"/>
>
> should effectively do nothing because you haven't told it what to change.
>
We can't do that. It would break most config.xml files around.
Anyhow, I'm documenting everything right now.
I suggest to complete what I'm doing getting a totally back compatible and documented Redirect, and later on we can have a new one, called "TheThing" (I'm joking :-), simply no name comes to my mind) that behaves as Noel says, and Redirect extends it just changing the defaults to keep the compatibility.
> > It might benefit by having some mailets that extend this with options
> > hardset and a more understandable name.
>
> Forward, for example. :-) By default, Forward requires nothing
> more than a
> recipient list, and should normally do nothing but change it. The Notify
> and Bounce mailets are also pretty clean.
>
> The one parameter whose default isn't related to "change/don't change" is
> <passthrough>. AbstractRedirect defaults it to false. AbstractNotify
> changes that so that Notify/Bounce mailets leave the original
> message in the
> spool by default. That behavior seems fine, so long as it is documented.
Doing that too.
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > As you already said, Redirect suffers from the need of backward
compatibility,
> > that we must guarantee. We could in the future create a new mailet, with
a
> > different name (which name BTW?) following more consistently the
conventions.
> This mailet has become a veritable swiss-army knife of confusion. :)
Always was. I propose that for undocumented defaults, that we change them
to be consistent (as discussed in this thread), and document the changes.
Doing:
<mailet match="All" class="Redirect"/>
should effectively do nothing because you haven't told it what to change.
> It might benefit by having some mailets that extend this with options
> hardset and a more understandable name.
Forward, for example. :-) By default, Forward requires nothing more than a
recipient list, and should normally do nothing but change it. The Notify
and Bounce mailets are also pretty clean.
The one parameter whose default isn't related to "change/don't change" is
<passthrough>. AbstractRedirect defaults it to false. AbstractNotify
changes that so that Notify/Bounce mailets leave the original message in the
spool by default. That behavior seems fine, so long as it is documented.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: subject prefix mailet or unaltered recipients in Redirect
Posted by Serge Knystautas <se...@lokitech.com>.
Vincenzo Gianferrari Pini wrote:
> As you already said, Redirect suffers from the need of backward compatibility, that we must guarantee. We could in the future create a new mailet, with a different name (which name BTW?) following more consistently the conventions.
This mailet has become a veritable swiss-army knife of confusion. :)
It might benefit by having some mailets that extend this with options
hardset and a more understandable name. I'm trying to think of a decent
example, but am blanking... are there some typical usages of this that
are useful?
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
As you already said, Redirect suffers from the need of backward compatibility, that we must guarantee. We could in the future create a new mailet, with a different name (which name BTW?) following more consistently the conventions.
Anyhow, I'm finalizing and going to test a new version of all the stuff with the generalized and consistent use of "unaltered", with lots of changes in the javadoc. I hope to commit it within a couple of hours. It would be great if you could redo your testing and comments on it very soon.
Thanks Joszef,
Vincenzo
> -----Original Message-----
> From: Hontvari Jozsef [mailto:hontvari3@solware.com]
> Sent: mercoledi 25 giugno 2003 21.06
> To: James Developers List
> Subject: Re: subject prefix mailet or unaltered recipients in Redirect
>
>
> > Redirect would insert a new, Redirected, message into the spool.
>
> I wasn't sure that it _always_ does this. I interpreted
> Vincenzo's email in
> this way and the doc isn't unambiquous either.
>
> This should be explicitly documented in Redirect and its descendants
> (forward etc.), it is a frequent question on the user's list. I already
> added a wiki comment about the endless loops related to this (otherwise
> reasonable) behaviour.
>
>
>
> > <mailet match="RecipientIs=xxx@flyordie.com" class="Redirect">
> > <static>true</static>
> > <prefix>[SPAM blackholes-easynet-nl]</prefix>
> > <passThrough>true</passThrough>
> > </mailet>
> >
> > Did you mean to have two copies? The Redirected one, and the original?
> Or
> > do you want to change passThrough to false?
>
> It should have been false.
>
> > > If you look at the attached message the body seems to be recursively
> > > included, this is surprising.
> >
> > The default for Redirect is that the inline type is BODY. Try using:
> >
> > <inline>UNALTERED</inline>
>
>
>
> that helped, thanks. This is another case where the Redirect use
> a different
> rule then the "if not specified it is not changed". BTW this
> should also be
> documented. I can submit a patch.
>
>
>
> ---------------------------------------------------------------------
> 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
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > Redirect would insert a new, Redirected, message into the spool.
> I wasn't sure that it _always_ does this.
Technically, it would depend upon a variety of parameters. For example, if
passthrough is false, then it may be possible to reuse the message.
> I already added a wiki comment about the endless loops related to
> this (otherwise reasonable) behaviour.
Looping, again, depends upon the matching criteria.
> > The default for Redirect is that the inline type is BODY. Try using:
> This is another case where the Redirect use a different rule
> then the "if not specified it is not changed". BTW this
> should also be documented. I can submit a patch.
Please do.
Personally, I wish that the Redirect defaults were different from what they
are, but changing them would potentially break existing configurations. In
my opinion,
<mailet match="All" class="Redirect" />
should be effectively a no-op, since nothing would change. On the other
hand, for defaults that are not documented, perhaps we can make some changes
to establish some consistency and sanity. Obviously, we'd have to document
the change(s).
Opinions?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: subject prefix mailet or unaltered recipients in Redirect
Posted by Hontvari Jozsef <ho...@solware.com>.
> Redirect would insert a new, Redirected, message into the spool.
I wasn't sure that it _always_ does this. I interpreted Vincenzo's email in
this way and the doc isn't unambiquous either.
This should be explicitly documented in Redirect and its descendants
(forward etc.), it is a frequent question on the user's list. I already
added a wiki comment about the endless loops related to this (otherwise
reasonable) behaviour.
> <mailet match="RecipientIs=xxx@flyordie.com" class="Redirect">
> <static>true</static>
> <prefix>[SPAM blackholes-easynet-nl]</prefix>
> <passThrough>true</passThrough>
> </mailet>
>
> Did you mean to have two copies? The Redirected one, and the original?
Or
> do you want to change passThrough to false?
It should have been false.
> > If you look at the attached message the body seems to be recursively
> > included, this is surprising.
>
> The default for Redirect is that the inline type is BODY. Try using:
>
> <inline>UNALTERED</inline>
that helped, thanks. This is another case where the Redirect use a different
rule then the "if not specified it is not changed". BTW this should also be
documented. I can submit a patch.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Gump
Posted by Danny Angus <da...@apache.org>.
> Great. :-) When the new modules are available, don't forget that we have
> some offers of help for the site. :-)
I remember!
RE: Gump
Posted by "Noel J. Bergman" <no...@devtech.com>.
Great. :-) When the new modules are available, don't forget that we have
some offers of help for the site. :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Gump
Posted by Danny Angus <da...@apache.org>.
As well as starting the "site" module and meddling with the builds for site and server I'll volunteer to sort out Gump too.
I've been meddling with Gump since last week, and have enough of the hang of it to sort the james moves out.
d.
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by "Noel J. Bergman" <no...@devtech.com>.
> However there is another problem, now I have an endless loop. The symptom
is
> obviously that the Redirects reinserts the message to the spool. I am not
> sure, if this is the intended behaviour in this case, or only an accident.
Redirect would insert a new, Redirected, message into the spool.
<mailet match="RecipientIs=xxx@flyordie.com" class="Redirect">
<static>true</static>
<prefix>[SPAM blackholes-easynet-nl]</prefix>
<passThrough>true</passThrough>
</mailet>
Did you mean to have two copies? The Redirected one, and the original? Or
do you want to change passThrough to false?
> If you look at the attached message the body seems to be recursively
> included, this is surprising.
Oh? Soren was reporting something similar, and reported the cause as:
The problem was that the original mimemessage was "attached" to
the new mimemessage, this behaviour in some circumstances (here
I am a little on thin ice, cause it did not always happen) led
to a self-referencing MimeMessage, and storing those leads to
the observed behaviour.
The default for Redirect is that the inline type is BODY. Try using:
<inline>UNALTERED</inline>
<passThrough>false</passThrough>
which should use the original message.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: subject prefix mailet or unaltered recipients in Redirect
Posted by Hontvari Jozsef <ho...@solware.com>.
I took out <to>unaltered</to>. It initializes correctly as expected.
However there is another problem, now I have an endless loop. The symptom is
obviously that the Redirects reinserts the message to the spool. I am not
sure, if this is the intended behaviour in this case, or only an accident.
If you look at the attached message the body seems to be recursively
included, this is surprising.
<mailet match="RecipientIs=xxx@flyordie.com" class="Redirect">
<static>true</static>
<prefix>[SPAM blackholes-easynet-nl]</prefix>
<passThrough>true</passThrough>
</mailet>
----- Original Message -----
From: "Vincenzo Gianferrari Pini" <vi...@praxis.it>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Tuesday, June 24, 2003 7:07 PM
Subject: RE: subject prefix mailet or unaltered recipients in Redirect
I'm just now adding systematically to most places the "unaltered" value as
acceptable, and behaving like not coding the parameter (i.e. null).
For backward compatibility, in Redirect the logic is to use <recipients>,
*if null use <to>*, if null no change.
I found an error in the current code: if <recipients> is null, will use
<to>; <to> can be "unaltered", but <recipients> can not be "unaltered", so
you get the error.
As now <recipients> will accept "unaltered", it will work.
In the meantime, just take out the <to>unaltered</to> line from your
config.xml: it is redundant.
Vincenzo
> -----Original Message-----
> From: Hontvari Jozsef [mailto:hontvari3@solware.com]
> Sent: martedi 24 giugno 2003 18.39
> To: James Developers List
> Subject: Re: subject prefix mailet or unaltered recipients in Redirect
>
>
> I tried it but it is not working. Looking at the source it seems
> to me that
> it follows the original class description.
>
> I used the following test:
> <mailet match="RecipientIs=xxx@flyordie.com" class="Redirect">
> <static>true</static>
> <prefix>[SPAM blackholes-easynet-nl]</prefix>
> <to>unaltered</to>
> <passThrough>true</passThrough>
> </mailet>
>
> This throws an exception at initialization saying that
> "Special ("magic") address found not allowed: unaltered, allowed
> values are
> "[postmaster,sender,returnPath]""
>
> The reason is that if the "recipients" parameter is not supplied
> it uses the
> "to" parameter. The "to" parameter contains "unaltered" in my case. But
> unaltered is not allowed in recipients.
>
> Here is the relevant code part:
>
> protected Collection getRecipients() throws MessagingException {
> Collection newRecipients = new HashSet();
> String addressList = (getInitParameter("recipients") == null)
> ? getInitParameter("to")
> : getInitParameter("recipients");
> // if nothing was specified, return null meaning no change
> if (addressList == null) {
> return null;
> }
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
I'm just now adding systematically to most places the "unaltered" value as acceptable, and behaving like not coding the parameter (i.e. null).
For backward compatibility, in Redirect the logic is to use <recipients>, *if null use <to>*, if null no change.
I found an error in the current code: if <recipients> is null, will use <to>; <to> can be "unaltered", but <recipients> can not be "unaltered", so you get the error.
As now <recipients> will accept "unaltered", it will work.
In the meantime, just take out the <to>unaltered</to> line from your config.xml: it is redundant.
Vincenzo
> -----Original Message-----
> From: Hontvari Jozsef [mailto:hontvari3@solware.com]
> Sent: martedi 24 giugno 2003 18.39
> To: James Developers List
> Subject: Re: subject prefix mailet or unaltered recipients in Redirect
>
>
> I tried it but it is not working. Looking at the source it seems
> to me that
> it follows the original class description.
>
> I used the following test:
> <mailet match="RecipientIs=xxx@flyordie.com" class="Redirect">
> <static>true</static>
> <prefix>[SPAM blackholes-easynet-nl]</prefix>
> <to>unaltered</to>
> <passThrough>true</passThrough>
> </mailet>
>
> This throws an exception at initialization saying that
> "Special ("magic") address found not allowed: unaltered, allowed
> values are
> "[postmaster,sender,returnPath]""
>
> The reason is that if the "recipients" parameter is not supplied
> it uses the
> "to" parameter. The "to" parameter contains "unaltered" in my case. But
> unaltered is not allowed in recipients.
>
> Here is the relevant code part:
>
> protected Collection getRecipients() throws MessagingException {
> Collection newRecipients = new HashSet();
> String addressList = (getInitParameter("recipients") == null)
> ? getInitParameter("to")
> : getInitParameter("recipients");
> // if nothing was specified, return null meaning no change
> if (addressList == null) {
> return null;
> }
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: subject prefix mailet or unaltered recipients in Redirect
Posted by Hontvari Jozsef <ho...@solware.com>.
I tried it but it is not working. Looking at the source it seems to me that
it follows the original class description.
I used the following test:
<mailet match="RecipientIs=xxx@flyordie.com" class="Redirect">
<static>true</static>
<prefix>[SPAM blackholes-easynet-nl]</prefix>
<to>unaltered</to>
<passThrough>true</passThrough>
</mailet>
This throws an exception at initialization saying that
"Special ("magic") address found not allowed: unaltered, allowed values are
"[postmaster,sender,returnPath]""
The reason is that if the "recipients" parameter is not supplied it uses the
"to" parameter. The "to" parameter contains "unaltered" in my case. But
unaltered is not allowed in recipients.
Here is the relevant code part:
protected Collection getRecipients() throws MessagingException {
Collection newRecipients = new HashSet();
String addressList = (getInitParameter("recipients") == null)
? getInitParameter("to")
: getInitParameter("recipients");
// if nothing was specified, return null meaning no change
if (addressList == null) {
return null;
}
----- Original Message -----
From: "Vincenzo Gianferrari Pini" <vi...@praxis.it>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Tuesday, June 24, 2003 10:02 AM
Subject: RE: subject prefix mailet or unaltered recipients in Redirect
No, you are right, it is missing in the class related part of the javadoc;
I'll fix it. I had only written it in the getRecipients() methot related
part of the javadoc:
getRecipients
protected Collection getRecipients()
throws MessagingException
Description copied from class: AbstractRedirect
Gets the recipients property. Returns the collection of recipients of the
new message, or null if no change is requested. Is a "getX()" method.
Overrides:
getRecipients in class AbstractRedirect
Returns:
the recipients init parameter or SpecialAddress.SENDER or
SpecialAddress.RETURN_PATH or null if missing
Vincenzo
> -----Original Message-----
> From: Hontvari Jozsef [mailto:hontvari3@solware.com]
> Sent: martedi 24 giugno 2003 9.47
> To: James Developers List
> Subject: Re: subject prefix mailet or unaltered recipients in Redirect
>
>
> Then it seems to me that the class javadoc doesn't reflect the actual
> behaviour.
>
> Description of the recipients parameter:
> A comma delimited list of email addresses for recipients of this
> message, it
> will use the "to" list if not specified.
>
> Do I miss something?
>
>
>
>
>
> ----- Original Message -----
> From: "Vincenzo Gianferrari Pini" <vi...@praxis.it>
> To: "James Developers List" <ja...@jakarta.apache.org>
> Sent: Tuesday, June 24, 2003 12:07 AM
> Subject: RE: subject prefix mailet or unaltered recipients in Redirect
>
>
> In the 2.2.0a7 Redirect, not coding any "recipient" parameter
> means keeping
> it unaltered. For example,in my "spam" processor, I coded the following:
>
> <!-- spam. -->
> <processor name="spam">
> <mailet match="All" class="Redirect">
> <static>true</static>
> <sender>postmaster</sender>
> <replyto>postmaster</replyto>
> <returnPath>null</returnPath>
> <inline>none</inline>
> <attachment>message</attachment>
> <prefix>[SPAM WARNING]</prefix>
> <passThrough>true</passThrough>
> <message>
> Based on our analyser, the attached message, addressed to you, has been
> classified as SPAM with a probability over 99%.
> Reading the subject you should be able to confirm the analysis,
> and if true
> you can delete without even opening it.
>
> Please don't reply to this e-mail as it has been automatically sent by the
> antivirus system.
>
> Regards, Postmaster xyz.it
> -----------------------------
> </message>
> </mailet>
>
> <mailet match="All" class="Forward">
> <forwardto>uce@ftc.gov</forwardto>
> <passThrough>true</passThrough>
> </mailet>
>
> <mailet match="All" class="ToRepository">
> <repositoryPath>file://var/mail/spam/</repositoryPath>
> </mailet>
> </processor>
>
> Is this what you mean?
>
> Vincenzo
>
> > -----Original Message-----
> > From: Hontvari Jozsef [mailto:hontvari3@solware.com]
> > Sent: lunedi 23 giugno 2003 22.36
> > To: james-dev@jakarta.apache.org
> > Subject: subject prefix mailet or unaltered recipients in Redirect
> >
> >
> > Because Outlook Express cannot filter messages (spam) based on
> headers, I
> > would need a mailet which adds a prefix to the subject. It mustn't do
> > anything else, e.g. it doesn't change the message id etc.
> >
> > This functionality is already in the code, in at least two
> places, in the
> > Redirect mailet and in the GenericListServ mailet. As I already
> > experienced
> > this it is not a simple operation, because it has to guess the
> appropriate
> > charset.
> >
> > I guess if there were an "unaltered" option in the recipients
> parameter of
> > the redirect mailet then it would make the job. Or maybe a
> separate mailet
> > is better. What do you think?
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
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
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
No, you are right, it is missing in the class related part of the javadoc; I'll fix it. I had only written it in the getRecipients() methot related part of the javadoc:
getRecipients
protected Collection getRecipients()
throws MessagingException
Description copied from class: AbstractRedirect
Gets the recipients property. Returns the collection of recipients of the new message, or null if no change is requested. Is a "getX()" method.
Overrides:
getRecipients in class AbstractRedirect
Returns:
the recipients init parameter or SpecialAddress.SENDER or SpecialAddress.RETURN_PATH or null if missing
Vincenzo
> -----Original Message-----
> From: Hontvari Jozsef [mailto:hontvari3@solware.com]
> Sent: martedi 24 giugno 2003 9.47
> To: James Developers List
> Subject: Re: subject prefix mailet or unaltered recipients in Redirect
>
>
> Then it seems to me that the class javadoc doesn't reflect the actual
> behaviour.
>
> Description of the recipients parameter:
> A comma delimited list of email addresses for recipients of this
> message, it
> will use the "to" list if not specified.
>
> Do I miss something?
>
>
>
>
>
> ----- Original Message -----
> From: "Vincenzo Gianferrari Pini" <vi...@praxis.it>
> To: "James Developers List" <ja...@jakarta.apache.org>
> Sent: Tuesday, June 24, 2003 12:07 AM
> Subject: RE: subject prefix mailet or unaltered recipients in Redirect
>
>
> In the 2.2.0a7 Redirect, not coding any "recipient" parameter
> means keeping
> it unaltered. For example,in my "spam" processor, I coded the following:
>
> <!-- spam. -->
> <processor name="spam">
> <mailet match="All" class="Redirect">
> <static>true</static>
> <sender>postmaster</sender>
> <replyto>postmaster</replyto>
> <returnPath>null</returnPath>
> <inline>none</inline>
> <attachment>message</attachment>
> <prefix>[SPAM WARNING]</prefix>
> <passThrough>true</passThrough>
> <message>
> Based on our analyser, the attached message, addressed to you, has been
> classified as SPAM with a probability over 99%.
> Reading the subject you should be able to confirm the analysis,
> and if true
> you can delete without even opening it.
>
> Please don't reply to this e-mail as it has been automatically sent by the
> antivirus system.
>
> Regards, Postmaster xyz.it
> -----------------------------
> </message>
> </mailet>
>
> <mailet match="All" class="Forward">
> <forwardto>uce@ftc.gov</forwardto>
> <passThrough>true</passThrough>
> </mailet>
>
> <mailet match="All" class="ToRepository">
> <repositoryPath>file://var/mail/spam/</repositoryPath>
> </mailet>
> </processor>
>
> Is this what you mean?
>
> Vincenzo
>
> > -----Original Message-----
> > From: Hontvari Jozsef [mailto:hontvari3@solware.com]
> > Sent: lunedi 23 giugno 2003 22.36
> > To: james-dev@jakarta.apache.org
> > Subject: subject prefix mailet or unaltered recipients in Redirect
> >
> >
> > Because Outlook Express cannot filter messages (spam) based on
> headers, I
> > would need a mailet which adds a prefix to the subject. It mustn't do
> > anything else, e.g. it doesn't change the message id etc.
> >
> > This functionality is already in the code, in at least two
> places, in the
> > Redirect mailet and in the GenericListServ mailet. As I already
> > experienced
> > this it is not a simple operation, because it has to guess the
> appropriate
> > charset.
> >
> > I guess if there were an "unaltered" option in the recipients
> parameter of
> > the redirect mailet then it would make the job. Or maybe a
> separate mailet
> > is better. What do you think?
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: subject prefix mailet or unaltered recipients in Redirect
Posted by Hontvari Jozsef <ho...@solware.com>.
Then it seems to me that the class javadoc doesn't reflect the actual
behaviour.
Description of the recipients parameter:
A comma delimited list of email addresses for recipients of this message, it
will use the "to" list if not specified.
Do I miss something?
----- Original Message -----
From: "Vincenzo Gianferrari Pini" <vi...@praxis.it>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Tuesday, June 24, 2003 12:07 AM
Subject: RE: subject prefix mailet or unaltered recipients in Redirect
In the 2.2.0a7 Redirect, not coding any "recipient" parameter means keeping
it unaltered. For example,in my "spam" processor, I coded the following:
<!-- spam. -->
<processor name="spam">
<mailet match="All" class="Redirect">
<static>true</static>
<sender>postmaster</sender>
<replyto>postmaster</replyto>
<returnPath>null</returnPath>
<inline>none</inline>
<attachment>message</attachment>
<prefix>[SPAM WARNING]</prefix>
<passThrough>true</passThrough>
<message>
Based on our analyser, the attached message, addressed to you, has been
classified as SPAM with a probability over 99%.
Reading the subject you should be able to confirm the analysis, and if true
you can delete without even opening it.
Please don't reply to this e-mail as it has been automatically sent by the
antivirus system.
Regards, Postmaster xyz.it
-----------------------------
</message>
</mailet>
<mailet match="All" class="Forward">
<forwardto>uce@ftc.gov</forwardto>
<passThrough>true</passThrough>
</mailet>
<mailet match="All" class="ToRepository">
<repositoryPath>file://var/mail/spam/</repositoryPath>
</mailet>
</processor>
Is this what you mean?
Vincenzo
> -----Original Message-----
> From: Hontvari Jozsef [mailto:hontvari3@solware.com]
> Sent: lunedi 23 giugno 2003 22.36
> To: james-dev@jakarta.apache.org
> Subject: subject prefix mailet or unaltered recipients in Redirect
>
>
> Because Outlook Express cannot filter messages (spam) based on headers, I
> would need a mailet which adds a prefix to the subject. It mustn't do
> anything else, e.g. it doesn't change the message id etc.
>
> This functionality is already in the code, in at least two places, in the
> Redirect mailet and in the GenericListServ mailet. As I already
> experienced
> this it is not a simple operation, because it has to guess the appropriate
> charset.
>
> I guess if there were an "unaltered" option in the recipients parameter of
> the redirect mailet then it would make the job. Or maybe a separate mailet
> is better. What do you think?
>
>
>
>
> ---------------------------------------------------------------------
> 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
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Sure it can be done, although this could be done everywhere,
> simply changing in AbstractRedirect.getSpecialAddress
> specialAddress = SpecialAddress.UNALTERED;
> to
> specialAddress = null;
Actually, I had in mind handling UNALTERED explicitly in the code, just as
we do the other special addresses.
> it would break in Redirect.getTo(Mail) the fact that if <to> is not
> coded, means set it as the <recipient> value
That would be an exception to the rule, for compatibility with the prior
behavior.
> I think that we should stress even more in the docs the adopted
> convention that not coding anything means null that means *no change*.
Sure. That is intuitive for the Administrator.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Sure it can be done, although this could be done everywhere, simply changing in AbstractRedirect.getSpecialAddress:
if(addressString.compareTo("unaltered") == 0) {
specialAddress = SpecialAddress.UNALTERED;
}
to
if(addressString.compareTo("unaltered") == 0) {
specialAddress = null;
}
But at this point it would break in Redirect.getTo(Mail) the fact that if <to> is not coded, means set it as the <recipient> value (this was the old behaviour that we must maintain for compatibility), while <to>unaltered</to> means leave it as it was before, even if we set <recipients> to something else.
I think that we should stress even more in the docs the adopted convention that not coding anything means null that means *no change*.
Vincenzo
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: martedi 24 giugno 2003 0.24
> To: James Developers List
> Subject: RE: subject prefix mailet or unaltered recipients in Redirect
>
>
> > In the 2.2.0a7 Redirect, not coding any "recipient" parameter
> > means keeping it unaltered.
>
> I was just going to point that out, having noticed it in the
> comments. But
> for ease of use, and symmetry, perhaps we should allow an explicit
> "unaltered", too? We already have it as a recognized special address.
>
> --- 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
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by "Noel J. Bergman" <no...@devtech.com>.
> In the 2.2.0a7 Redirect, not coding any "recipient" parameter
> means keeping it unaltered.
I was just going to point that out, having noticed it in the comments. But
for ease of use, and symmetry, perhaps we should allow an explicit
"unaltered", too? We already have it as a recognized special address.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: subject prefix mailet or unaltered recipients in Redirect
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
In the 2.2.0a7 Redirect, not coding any "recipient" parameter means keeping it unaltered. For example,in my "spam" processor, I coded the following:
<!-- spam. -->
<processor name="spam">
<mailet match="All" class="Redirect">
<static>true</static>
<sender>postmaster</sender>
<replyto>postmaster</replyto>
<returnPath>null</returnPath>
<inline>none</inline>
<attachment>message</attachment>
<prefix>[SPAM WARNING]</prefix>
<passThrough>true</passThrough>
<message>
Based on our analyser, the attached message, addressed to you, has been classified as SPAM with a probability over 99%.
Reading the subject you should be able to confirm the analysis, and if true you can delete without even opening it.
Please don't reply to this e-mail as it has been automatically sent by the antivirus system.
Regards, Postmaster xyz.it
-----------------------------
</message>
</mailet>
<mailet match="All" class="Forward">
<forwardto>uce@ftc.gov</forwardto>
<passThrough>true</passThrough>
</mailet>
<mailet match="All" class="ToRepository">
<repositoryPath>file://var/mail/spam/</repositoryPath>
</mailet>
</processor>
Is this what you mean?
Vincenzo
> -----Original Message-----
> From: Hontvari Jozsef [mailto:hontvari3@solware.com]
> Sent: lunedi 23 giugno 2003 22.36
> To: james-dev@jakarta.apache.org
> Subject: subject prefix mailet or unaltered recipients in Redirect
>
>
> Because Outlook Express cannot filter messages (spam) based on headers, I
> would need a mailet which adds a prefix to the subject. It mustn't do
> anything else, e.g. it doesn't change the message id etc.
>
> This functionality is already in the code, in at least two places, in the
> Redirect mailet and in the GenericListServ mailet. As I already
> experienced
> this it is not a simple operation, because it has to guess the appropriate
> charset.
>
> I guess if there were an "unaltered" option in the recipients parameter of
> the redirect mailet then it would make the job. Or maybe a separate mailet
> is better. What do you think?
>
>
>
>
> ---------------------------------------------------------------------
> 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