You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@james.apache.org by Steve Brewin <sb...@synsys.com> on 2004/02/29 19:19:20 UTC

Support for MDN MIME content types?

Hi,

The host environment for jSieve is required to support RFC 1892. In
particular, the creation of MIME content types Multipart/report and
message/disposition-notification.

This means my demonstration of jSieve invoked from a James Mailet needed
this support, which I achieved by extending
javax.mail.internet.MimeMultipart and implementing
javax.activation.DataContentHandler's for the each of the new MIME content
types. The resultant classes are packaged into a .jar that must live in the
James .sar.

Strictly speaking, these are JavaMail / Java Activation Framework
extensions. James has no direct dependency on them. However, they are
generally useful to anyone wishing to implement MDN (Message Disposition
Notification).

Do we want to create a home for javamail extensions in order to make them
available for re-use by James and its Mailets (might be
org.apache.james.javamail or a new sub-project) or deal with such issues on
an ad-hoc basis?

-- Steve


Re: Support for MDN MIME content types?

Posted by Serge Knystautas <se...@lokitech.com>.
Steve Brewin wrote:
> Do we want to create a home for javamail extensions in order to make them
> available for re-use by James and its Mailets (might be
> org.apache.james.javamail or a new sub-project) or deal with such issues on
> an ad-hoc basis?

That's a tough one.  We don't really have very many, so I'm not sure if 
it's worth an extra module at this point.  This is almost like a 
"commons" module for James.  Can anyone think of any other libraries 
that might be useful?

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


RE: Support for MDN MIME content types?

Posted by Danny Angus <da...@apache.org>.
<snip>

> Strictly speaking, these are JavaMail / Java Activation Framework
> extensions. James has no direct dependency on them. However, they are
> generally useful to anyone wishing to implement MDN (Message Disposition
> Notification).
> 
> Do we want to create a home for javamail extensions in order to make them
> available for re-use by James and its Mailets (might be
> org.apache.james.javamail or a new sub-project) or deal with such 
> issues on
> an ad-hoc basis?

I think it would be a good idea to have a seperate module for Java Mail implementation classes, unless we're going to have James specific Java Mail implementations, in which case it wouldn't.. By which I'm thinking mainly of outgoing SMTP, an SMTP "Transport" provider for Java Mail might well have a James specific implementation allowing it to make direct use of James resources.

Then again it might survive as a Java Mail/ Mailet implementation, providing enhanced outgoing SMTP for any Mailet Context using the context for access to DNS and spooling, and providing connection re-use, message aggregation, and deliver event notification to the Mailet Context.

... so I can see two equally valid answers here :-(

d.



RE: Support for MDN MIME content types?

Posted by "Noel J. Bergman" <no...@devtech.com>.
Steve,

> The host environment for jSieve is required to support RFC 1892.

Actually, that is obsolete.  The three current RFC's are:

  http://www.ietf.org/rfc/rfc3462.txt
  http://www.ietf.org/rfc/rfc3463.txt
  http://www.ietf.org/rfc/rfc3464.txt

> In particular, the creation of MIME content types Multipart/report
> and message/disposition-notification.

Andreas Göggerle's DSNBounce Mailet had the same issue.  For now it uses
text/plain, but we do want to support message/delivery-status.

> I achieved by extending javax.mail.internet.MimeMultipart and implementing
> javax.activation.DataContentHandler's for the each of the new MIME content
> types. The resultant classes are packaged into a .jar that must live in
the
> James .sar.

Great.  Sounds like we've a framework for extending the MIME types James
needs, at least for when we use JavaMail.

> Do we want to create a home for javamail extensions

Probably so, and org.apache.james.javamail is OK for now, unless we want to
setup a org.apache.javamail for generic JavaMail extensions?  I don't
believe that we want to use org.apache.mail, which was the original package
name for James, for JavaMail specific code.

	--- Noel