jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vianen, Jeroen van" <jeroen.van.via...@satama.com>
Subject RE: New version of Mailer tag
Date Tue, 10 May 2005 14:00:14 GMT
Hi Pete,

I don't think so. It's JavaMail trying to create a piece of boundary String
that's unique for the given (multipart) mail. They're always in that format.


Regards,


Jeroen

-----Original Message-----
From: pete.storey@kisstechnologies.co.uk
[mailto:pete.storey@kisstechnologies.co.uk] 
Sent: dinsdag 10 mei 2005 14:00
To: Tag Libraries Developers List
Subject: RE: New version of Mailer tag

One other odd thing I've noticed with the old tag (and my version, and
probably this one too), is that the part ID of the mime part gets
incremented by JavaMail every time it sends an email so if the server has
been running for a while you'll end up with
boundary="----=_Part_10000_14761595.1115726191897" etc.  Isn't really a
problem I can see at the moment but could it be on a large scale system?
cheers
Pete






"Vianen, Jeroen van" <jeroen.van.vianen@satama.com>
10/05/2005 07:56
Please respond to "Tag Libraries Developers List"
 
        To:     Tag Libraries Developers List 
<taglibs-dev@jakarta.apache.org>
        cc: 
        Subject:        RE: New version of Mailer tag


Hi Pete, 

> -----Original Message-----
> From: pete.storey@kisstechnologies.co.uk
[mailto:pete.storey@kisstechnologies.co.uk] 
> Sent: maandag 9 mei 2005 20:02
> To: Tag Libraries Developers List
> Subject: RE: New version of Mailer tag
> 
> Ah ha yes this will do it though it's a slight prob for us (and
probably
> 
> others) in that it isn't backwards compatible with the mailer v1 tag
so
you can't just plop it into your current implementations (and we have a lot
already existing).  Also can't run on Tomcat 4.x which again we (and
others)
use a lot.

I deliberately broke backwards compatibility to make it easier to implement
the HTML / plain text parts and the signing and encrypting of e-mails.

> One random thought looking at it - why are the attachments a
multipart/related part of another part?  Doesn't this mean you don't see
them if you have a text only (but mime compliant) browser?  I would have
thought it would be better to have say a "related" tag which puts in
multipart/related things such as images for an HTML email, which returns a
CID, and then a seperate generic attach tag to do normal attachments in a
multipart/mixed format?

The normal way would be (I guess) to have either the following:

<mt:mail type="multipart/alternative">
                 <mt:part type="text/plain">...</mt:part>
                 <mt:part type="text/html">...
                                 <mt:attach />
                 </mt:part>
</mt:mail>

Where the attachments are only relevant for the HTML version of the message
(and therefore multipart/related).

Or the following:

<mt:mail type="text/html">
                 ...
                 <mt:attach/>
</mt:mail>

Where you have a plain text mail with attachments (multipart/mixed).

Regards,


Jeroen

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


email protected and scanned by AdvascanTM - keeping email useful -
www.advascan.com 





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


Mime
View raw message