Mailet API: Mail Attributes, Recipient Attributes, Mail.duplicate()

[ap...@bago.org]

Hi all,

While implementing DSN support for James I've had a doubt: are attributes
supposed to be duplicated when Mail.duplicate() is calles? I think they
should be duplicated but currently MailImpl simply does a attributes.clone()
that simply clone the HashMap and not the attributes!

Another thing I don't like is the way recipients are handled: currently, via
API, I get access to the MailAddress collection and I can do everything,
share the collection with other mailimpls and similar bad things.

I also need to add recipient attributes working like mail attributes: can we
add this feature to the Mailet APIs for 3.0?

My current workaround has been to add a Mail attribute containing and
Hashmap of recipients pointing to their Attributes: the main problem is that
adding this object as a mail attribute will create problems when the mail
will be duplicated.

I think we should add to MailetAPIs methods to addrecipient,
removerecipient, changerecipient, getRecipientAttribute and
setRecipientAttribute.


Stefano


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

Re: Mailet API: Mail Attributes, Recipient Attributes, Mail.duplicate()

[Serge Knystautas <sk...@gmail.com>]

On 5/30/05, Noel J. Bergman <no...@devtech.com> wrote:
> Serge Knystautas wrote:
> 
> > Noel J. Bergman <no...@devtech.com> wrote:
> > > Sounds as if we want a Recipient class for internal use,
> > > rather than just a String containing the e-mail address.
> 
> > I don't remember why we started allowing recipients to be String
> > instead of MailAddress.  MailAddress was designed to be for
> > recipients, but I guess it was clumsy to use or something.  Anyway,
> > then this would have been perfect to extend MailAddress with one that
> > has attributes.  The idea of per-recipient attributes was never
> > considered (AFAIK).
> 
> I look at it as a Recipient HAS a MailAddress rather than IS a MailAddress,
> but in most cases that might be a bit hair-splitting.

Is there a case where a recipient does NOT have a mailaddress?

-- 
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

Re: Mailet API: Mail Attributes, Recipient Attributes, Mail.duplicate()

[ap...@bago.org]

> I don't believe that we need to toss out the existing API 
> wholesale.  And we can support API evolution by realizing 
> that the Processor is a Mailet Container, and when we 
> implement <processor name="..." class="...">, we can 
> implement different containers as necessary to support 
> evolution of the API.

Here is my list of needs for MailetAPI:

A] Per Recipient Attributes: I need this for DSN support. In ESMTP DSN in
the SMTP session a client is allowed to add a NOTIFY and an ORCPT attributes
for each recipient (RCPT TO: <re...@email.com> NOTIFY=SUCCESS,DELAY
ORCPT=rfc822;<or...@domain.com>).

B] Recipient collection incapsulation: I think we should deny the direct
access to the recipient collection. I probably prefer an addRecipient,
removeRecipient, recipientIterator(), addRecipientAttribute,
removeRecipientAttribute, recipientAttributeIterator(). For DSN purposes it
would be cool to be able to keep track of aliasing:
"changeRecipientAddress()"?!

C] notifyDeliveryStatus() in MailetContext (to replace bounce() that
represent only one specific status): the james2.2.0 "bounceProcessor"
handling is not enough for full DSN support. We need to be able to notify
also DELAYs and for DELAYs we should send a new copy of the mail to the
bounceProcessor at each delay. I think we should add a method in the
MailetContext to allow the container to decide wether to send notifications
or not , wether to copy the message or not. I think that we should remove
the bounceProcessor and the use of Mail.ERROR in the mailets and
alternatively add a container configuration to be able to customize the
error handling.

D] Named destinations / repositories: I think you already discussed this ( I
found a wiki page about MailetAPIv3 and repositories:
http://wiki.apache.org/james/JamesMailetV3). How old is this page?

E] If we add SpoolRepositories to the API then we should consider to
introduce a better accept(): I think that JMS consumer way to declare
attributes for the messages they are able to consume is a good way.

F] Fully remove "MailImpl" from the bundled matcher/mailets by moving needed
methods to the Mail interface.

G] Remove the "void sendMail(MailAddress sender, Collection recipients,
MimeMessage msg, String state)" methods from mailetContext: this is only
used by LocalDelivery to handle ERROR notifications and this would be solved
by notifyDeliveryStatus().

H] Add the definitions of MailDeliveryStatus/es and
PerRecipientDeliveryStatus/es in the API: Mailets should know how to add
delivery status informations to the Mail and how the can provide good
information to MailetContext.notifyDeliveryStatus().

I] Why do we have "Iterator getSMTPHostAddresses(String domainName);" and
"Collection getMailServers(String host);" ? They seems very similar. Do we
need both? The first is used in RemoteDelivery while the second is used in
AbstractRedirect and SenderInFakeDomain.

PS: someone should add this new mailing-list to this page:
http://james.apache.org/mail.html

Stefano


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

RE: Mailet API: Mail Attributes, Recipient Attributes, Mail.duplicate()

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

Serge Knystautas wrote:

> Noel J. Bergman <no...@devtech.com> wrote:
> > Sounds as if we want a Recipient class for internal use,
> > rather than just a String containing the e-mail address.

> I don't remember why we started allowing recipients to be String
> instead of MailAddress.  MailAddress was designed to be for
> recipients, but I guess it was clumsy to use or something.  Anyway,
> then this would have been perfect to extend MailAddress with one that
> has attributes.  The idea of per-recipient attributes was never
> considered (AFAIK).

I look at it as a Recipient HAS a MailAddress rather than IS a MailAddress,
but in most cases that might be a bit hair-splitting.

> I wanted in terms of nesting Collections was to implement what we
> wrote into the API years ago...
> http://james.apache.org/mailet/org/apache/mailet/Matcher.html.  I
> rewrote the LinearProcessor to handle this, but I don't think I
> finished testing and it needs to be migrated to the MAIN (trunk,
> whatever SVN calls it).

Post some code to server-dev if you want other eyes to review.  :-)

> > What do we propose to do about compatibility with existing matchers
> > and mailets?  One approach would be to keep the existing methods as
> > they are (setter/getter pair for Collection<String>), and
> > reimplement the old methods in terms of the new ones.

> I can't say I have any constructive idea on here without just tossing
> the whole API out and starting over with these issues in mind.

I don't believe that we need to toss out the existing API wholesale.  And we
can support API evolution by realizing that the Processor is a Mailet
Container, and when we implement <processor name="..." class="...">, we can
implement different containers as necessary to support evolution of the API.

	--- Noel


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

RE: Mailet API: Mail Attributes, Recipient Attributes, Mail.duplicate()

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

Serge Knystautas wrote:

> Noel J. Bergman <no...@devtech.com> wrote:
> > Sounds as if we want a Recipient class for internal use,
> > rather than just a String containing the e-mail address.

> I don't remember why we started allowing recipients to be String
> instead of MailAddress.  MailAddress was designed to be for
> recipients, but I guess it was clumsy to use or something.  Anyway,
> then this would have been perfect to extend MailAddress with one that
> has attributes.  The idea of per-recipient attributes was never
> considered (AFAIK).

I look at it as a Recipient HAS a MailAddress rather than IS a MailAddress,
but in most cases that might be a bit hair-splitting.

> I wanted in terms of nesting Collections was to implement what we
> wrote into the API years ago...
> http://james.apache.org/mailet/org/apache/mailet/Matcher.html.  I
> rewrote the LinearProcessor to handle this, but I don't think I
> finished testing and it needs to be migrated to the MAIN (trunk,
> whatever SVN calls it).

Post some code to server-dev if you want other eyes to review.  :-)

> > What do we propose to do about compatibility with existing matchers
> > and mailets?  One approach would be to keep the existing methods as
> > they are (setter/getter pair for Collection<String>), and
> > reimplement the old methods in terms of the new ones.

> I can't say I have any constructive idea on here without just tossing
> the whole API out and starting over with these issues in mind.

I don't believe that we need to toss out the existing API wholesale.  And we
can support API evolution by realizing that the Processor is a Mailet
Container, and when we implement <processor name="..." class="...">, we can
implement different containers as necessary to support evolution of the API.

	--- Noel

Re: Mailet API: Mail Attributes, Recipient Attributes, Mail.duplicate()

[Serge Knystautas <sk...@gmail.com>]

On 5/29/05, Noel J. Bergman <no...@devtech.com> wrote:
> Sounds as if we want a Recipient class for internal use, rather than just a
> String containing the e-mail address.  And if we are going to make this
> change, we should at the same time attack the problem Serge wanted to
> address, which supports having nested collections, not just Strings and/or
> Recipients.

I don't remember why we started allowing recipients to be String
instead of MailAddress.  MailAddress was designed to be for
recipients, but I guess it was clumsy to use or something.  Anyway,
then this would have been perfect to extend MailAddress with one that
has attributes.  The idea of per-recipient attributes was never
considered (AFAIK).

All I wanted in terms of nesting Collections was to implement what we
wrote into the API years ago...
http://james.apache.org/mailet/org/apache/mailet/Matcher.html.  I
rewrote the LinearProcessor to handle this, but I don't think I
finished testing and it needs to be migrated to the MAIN (trunk,
whatever SVN calls it).

> What do we propose to do about compatibility with existing matchers and
> mailets?  One approach would be to keep the existing methods as they are
> (setter/getter pair for Collection<String>), and reimplement the old methods
> in terms of the new ones.

I can't say I have any constructive idea on here without just tossing
the whole API out and starting over with these issues in mind.

-- 
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

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

RE: Mailet API: Mail Attributes, Recipient Attributes, Mail.duplicate()

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

Stefano Bagnara wrote:

> While implementing DSN support for James I've had a doubt: are attributes
> supposed to be duplicated when Mail.duplicate() is calles? I think they
> should be duplicated but currently MailImpl simply does a
attributes.clone()
> that simply clone the HashMap and not the attributes!

Sounds like a bug.  Please submit a patch.

> I don't like [the] way recipients are handled
> I get access to the MailAddress collection and I can do everything,
> share the collection with other mailimpls and similar bad things.

> I also need to add recipient attributes working like mail attributes

> I think we should add to MailetAPIs methods to addrecipient,
> removerecipient, changerecipient, getRecipientAttribute and
> setRecipientAttribute.

Sounds as if we want a Recipient class for internal use, rather than just a
String containing the e-mail address.  And if we are going to make this
change, we should at the same time attack the problem Serge wanted to
address, which supports having nested collections, not just Strings and/or
Recipients.

What do we propose to do about compatibility with existing matchers and
mailets?  One approach would be to keep the existing methods as they are
(setter/getter pair for Collection<String>), and reimplement the old methods
in terms of the new ones.

Any proposals for the new method signatures?

Done right, we can roll this into the build without breaking anything, and
that means we can ship it as a new feature without an API break.

	--- Noel


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