[no virus] RE: NotifySender vs bounce method (was: Exception calling NotifySender)

[Vincenzo Gianferrari Pini <vi...@praxis.it>]

Noel

I made some preliminary changes to Redirect in order to support Return-Path, and soon will work on the other mailets to subclass them.

In the meantime, please have a look at the enclosed Redirect_1 to review and in particular comment on two things for me:

1) Search for the string "returnPath". I managed it similarly to "replyTo" but with some differences:

	a) The new "returnPath" init parameter accepts not only the special values "postmaster" and "sender" but also "empty".

	b) The new private variable "returnPath" is defined as String instead of MailAddress in order to hold also the special value "" in case <returnPath>empty</returnPath> is set.

	c) Please check the management of a <returnPath>sender</returnPath> (which would default to the current behaviour of Redirect): it will just be ignored.

2) I think (unless there is something missing to me) that there is a bug in Redirect, that I hopefully fixed in the attached code (search for "multithreading"): in case of "non static" parameters, the mailet is using in service(Mail) some instance variables (for example "replyTo") that would be shared by the different spoolmanager threads, causing problems specially in a multiprocessor machine; I changed to the use of new variables local to the method.

Thanks 

Vincenzo

> -----Original Message-----
> From: Vincenzo Gianferrari Pini
> [mailto:vincenzo.gianferraripini@praxis.it]
> Sent: gioved� 15 maggio 2003 10.09
> To: James Developers List
> Subject: RE: NotifySender vs bounce method (was: Exception calling
> NotifySender)
> 
> 
> > HOWEVER, an even better way, if you really want to help clean 
> up the code,
> > would be to do some work in Redirect so that we can modify NotifySender,
> > NotifyPostmaster, Forward, Bounce, etc., to all be subclasses 
> of Redirect.
> > That would lead to vastly improved code re-use within James.
> > 
> > For example, a bounce/notify message would be INLINE=NONE, 
> > ATTACHMENT=BODY.
> > Forward would be INLINE=UNALTERED.  The subclasses would override
> > getInlineType and getAttachmentType to control those values.  
> But although
> > we can control the Sender, Recipients, Reply-To, etc., there is 
> no control
> > over the Return-Path, so that would have to be added.
> Looks more ambitious but much cleaner and useful. I will have a 
> look at the code and be back on that.
> 
> Vincenzo
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
> 

Re: Redirect - notify/bounce processing changes

[Serge Knystautas <se...@lokitech.com>]

Noel J. Bergman wrote:
>>  b) The new private variable "returnPath" is defined as String instead
>>     of MailAddress in order to hold also the special value "" in case
> 
>        <returnPath>empty</returnPath> is set.
> 
> Well, I prefer consistancy, but I see your point.  Does it make sense to
> modify MailAddress to support the special "<>" empty address?

I would prefer to define empty as Null.  I believe the RFC ever refers 
to it as a null sender.  I would therefore want to leave MailAddress 
unchanged, and just always have empty in these mailets set field to null 
instead of "".

-- 
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

Redirect - notify/bounce processing changes

["Noel J. Bergman" <no...@devtech.com>]

Vincenzo,

As you can see, I haven't read your code, yet, but I'm going back over your
messages, now that I've gotten some other changes out of the way.  :-)

> I managed [returnPath] similarly to "replyTo" but with some differences:
>   a) The new "returnPath" init parameter accepts not only the special
>      values "postmaster" and "sender" but also "empty".

This seems good.  :-)

>   b) The new private variable "returnPath" is defined as String instead
>      of MailAddress in order to hold also the special value "" in case
       <returnPath>empty</returnPath> is set.

Well, I prefer consistancy, but I see your point.  Does it make sense to
modify MailAddress to support the special "<>" empty address?

>   c) Please check the management of a <returnPath>sender</returnPath>
>      (which would default to the current behaviour of Redirect): it
>      will just be ignored.

Will look at your latest code.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org