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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: true postmaster postmaster null none message [SPAM WARNING] true 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 - [EMAIL PROTECTED] true file://var/mail/spam/ Is this what you mean? Vincenzo > -Original Message- > From: Hontvari Jozsef [mailto:[EMAIL PROTECTED] > Sent: lunedi 23 giugno 2003 22.36 > To: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: subject prefix mailet or unaltered recipients in Redirect
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 is not
coded, means set it as the value (this was the old behaviour that we must
maintain for compatibility), while unaltered means leave it as it was before,
even if we set 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:[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: subject prefix mailet or unaltered recipients in Redirect
> 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 is not > coded, means set it as the 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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" <[EMAIL PROTECTED]> To: "James Developers List" <[EMAIL PROTECTED]> 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: true postmaster postmaster null none message [SPAM WARNING] true 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 - [EMAIL PROTECTED] true file://var/mail/spam/ Is this what you mean? Vincenzo > -Original Message- > From: Hontvari Jozsef [mailto:[EMAIL PROTECTED] > Sent: lunedi 23 giugno 2003 22.36 > To: [EMAIL PROTECTED] > 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: [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]
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:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > To: "James Developers List" <[EMAIL PROTECTED]> > 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: > > > > > true > postmaster > postmaster > null > none > message > [SPAM WARNING] > true > > 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 > - > > > > > [EMAIL PROTECTED] > true > > > > file://var/mail/spam/ > > > > Is this what you mean? > > Vincenzo > > > -Original Message- > > From: Hontvari Jozsef [mailto:[EMAIL PROTECTED] > > Sent: lunedi 23 giugno 2003 22.36 > > To: [EMAIL PROTECTED] > > 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: [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]
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:
true
[SPAM blackholes-easynet-nl]
unaltered
true
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" <[EMAIL PROTECTED]>
To: "James Developers List" <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]
> 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" <[EMAIL PROTECTED]>
> To: "James Developers List" <[EMAIL PROTECTED]>
> 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:
>
>
>
>
> true
> postmaster
> postmaster
> null
> none
> message
> [SPAM WARNING]
> true
>
> 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
> -----
>
>
>
>
> [EMAIL PROTECTED]
> true
>
>
>
> file://var/mail/spam/
>
>
>
> Is this what you mean?
>
> Vincenzo
>
> > -Original Message-
> > From: Hontvari Jozsef [mailto:[EMAIL PROTECTED]
> > Sent: lunedi 23 giugno 2003 22.36
> > To: [EMAIL PROTECTED]
> > 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.
> >
> &
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 , *if null use
*, if null no change.
I found an error in the current code: if is null, will use ; can
be "unaltered", but can not be "unaltered", so you get the error.
As now will accept "unaltered", it will work.
In the meantime, just take out the unaltered line from your config.xml: it is
redundant.
Vincenzo
> -Original Message-
> From: Hontvari Jozsef [mailto:[EMAIL PROTECTED]
> 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:
>
> true
> [SPAM blackholes-easynet-nl]
> unaltered
> true
>
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: subject prefix mailet or unaltered recipients in Redirect
I took out unaltered. 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.
true
[SPAM blackholes-easynet-nl]
true
- Original Message -
From: "Vincenzo Gianferrari Pini" <[EMAIL PROTECTED]>
To: "James Developers List" <[EMAIL PROTECTED]>
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 ,
*if null use *, if null no change.
I found an error in the current code: if is null, will use
; can be "unaltered", but can not be "unaltered", so
you get the error.
As now will accept "unaltered", it will work.
In the meantime, just take out the unaltered line from your
config.xml: it is redundant.
Vincenzo
> -Original Message-
> From: Hontvari Jozsef [mailto:[EMAIL PROTECTED]
> 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:
>
> true
> [SPAM blackholes-easynet-nl]
> unaltered
> true
>
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- Begin Message ---
Message:
--=_Part_10_14801602.1056475215500
Content-Type: multipart/alternative;
boundary="=_Part_11_31534957.1056475215500"
--=_Part_11_31534957.1056475215500
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message:
--=_Part_8_12470752.1056475215093
Content-Type: multipart/alternative;
boundary="=_Part_9_14949315.1056475215093"
--=_Part_9_14949315.1056475215093
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message:
--=_Part_6_1465214.1056475214906
Content-Type: multipart/alternative;
boundary="=_Part_7_30462244.1056475214906"
--=_Part_7_30462244.1056475214906
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message:
--=_Part_4_19255406.1056475213671
Content-Type: multipart/alternative;
boundary="=_Part_5_26670261.1056475213671"
--=_Part_5_26670261.1056475213671
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message:
--=_Part_2_21559496.1056475213343
Content-Type: multipart/alternative;
boundary="=_Part_3_29705835.1056475213343"
--=_Part_3_29705835.1056475213343
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message:
--=_Part_0_10233621.1056475213109
Content-Type: multipart/alternative;
boundary="=_Part_1_30008954.1056475213109"
--=_Part_1_30008954.1056475213109
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message:
szi=F3ka2
--=_Part_1_30008954.1056475213109--
--=_Part_0_10233621.1056475213109--
--=_Part_3_29705835.1056475213343--
--=_Part_2_21559496.10564
RE: subject prefix mailet or unaltered recipients in Redirect
> 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. true [SPAM blackholes-easynet-nl] true 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: UNALTERED false which should use the original message. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. > > true > [SPAM blackholes-easynet-nl] > true > > > 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: > > UNALTERED 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: subject prefix mailet or unaltered recipients in Redirect
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:[EMAIL PROTECTED] > 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. > > > > > > > true > > [SPAM blackholes-easynet-nl] > > true > > > > > > 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: > > > > UNALTERED > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. 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, 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: subject prefix mailet or unaltered recipients in Redirect
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. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: subject prefix mailet or unaltered recipients in Redirect
> > 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: 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 . 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: subject prefix mailet or unaltered recipients in Redirect
> > > > 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: > > > > 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 > . 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: subject prefix mailet or unaltered recipients in Redirect
> > 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 ... <> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: subject prefix mailet or unaltered recipients in Redirect
> > > > > 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 ... <> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
