<< Back to previous view

[GLASSFISH-20772] GlassFish JavaMail alters Content-Disposition of MIME Parts on MultiPart message with inlined jpeg image Created: 20/Aug/13  Updated: 23/Aug/13

Status: Open
Project: glassfish
Component/s: mail
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pranahata Assignee: Bill Shannon
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Participants: Bill Shannon and pranahata


When sending an email with an inlined jpeg image using a multipart MIME message with the image being a MIME part declared with:
Content-Disposition: inline;

and referenced via cid.

GlassFish converts the mime part from being 'inline' to being 'attachment':

Content-Disposition: attachment;

And hence the image is not embedded on the email. Same test case sent via JavaSE happens correctly.

This doesn't happen for png images. inlined png images are preserved as inlined

Comment by Bill Shannon [ 21/Aug/13 10:52 PM ]

I'm sure GlassFish isn't changing the message. What evidence do you have that it is?

Are you using the same mail server for both the GlassFish test and the Java SE test?

Turn on JavaMail Session debugging by using session.setDebug(true) and the server log file will show you exactly what JavaMail is sending.

Comment by pranahata [ 22/Aug/13 05:50 AM ]

Hey Bill,

I deliberately made a provocative subject line to try to get attention as soon as possible. But there is something going on with the javamail implementation bundled in glassfish.

The only difference i can see in both environments is the mailcap file in the METAINF of java.mail-1.5.0.jar

The one in glassfish has the following two lines commented:


  1. can't support image types because java.awt.Toolkit doesn't work on servers
    #image/gif;; x-java-content-handler=com.sun.mail.handlers.image_gif
    #image/jpeg;; x-java-content-handler=com.sun.mail.handlers.image_jpeg

I think when running on SE, there is a mailcap file in the JRE installation dir that has those two lines enabled.

If i do:

MailcapCommandMap mailcap = (MailcapCommandMap)CommandMap.getDefaultCommandMap();
String[] mimeTypes = mailcap.getMimeTypes();
log.debug("mailCap types are {}", Arrays.asList(mimeTypes));

In SE shows about 7, in GF environment shows about 5

I've tried a few things including adding a mailcap file to my web app and playing with the glassfis-web delegate class loader flag but no luck.

With setDebug(true) as you said, the output shows as Content-Disposition: inline; but the received email shows the jpeg as Content-Disposition: attachment;

Comment by Bill Shannon [ 23/Aug/13 07:27 PM ]

If the received message is different than the sent message, it's your mail server that's changing the message, not JavaMail.

I have a hard time believing that the sent message is the same both in SE and in GlassFish, but different messages are being received. If that's reproducible, I'd like to see the debug output.

The different mailcap entries shouldn't have any effect here. The mailcap entries are only used when converting a byte stream of a given MIME type to a Java object; the x-java-content-hander entry refers to the class that does the conversion. You should never need to do that when sending a message.

It might be easier to continue debugging your problem in email; send me details at javamail_ww@oracle.com.

[GLASSFISH-6816] Mail Debug Messages are written with INFO level (only some messages -- see comments) Created: 19/Nov/08  Updated: 18/Oct/10

Status: Open
Project: glassfish
Component/s: mail
Affects Version/s: 9.1peur2
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: mkarg Assignee: Bill Shannon
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 6,816
Participants: Bill Shannon, mkarg and peterwx


When enabling the Mail Debugging, then the debug messages are written using INFO

thread-pool-1; w: 5;|
DEBUG: not loading file: C:\Programme\Java\jdk1.6.0_10\jre\lib\javamail.providers|#]

From the view of an administrator, this is the wrong level. Since it is DEBUG
information, it should be logged using a level of FINE, FINER or FINEST.

INFO should stay reserved for information of higher importance, to be able to
separate "essential" from "just debug" information.

Comment by Bill Shannon [ 19/Nov/08 09:39 AM ]

I'm not sure why this is happening.

When a JavaMail resource is created, it's configured to route its debug
output through a stream that converts the output into log messages.
The core of MailLogOutputStream is:

if (msg.startsWith("DEBUG"))
logger.log(Level.FINE, msg);
logger.log(Level.FINER, msg);

Are you using a JavaMail Session configured as a resource? Or are you creating
your own JavaMail Session and enabling debug output? In the latter case,
perhaps the app server is collecting all output to System.out and turning it
into log messages at INFO level?

Comment by mkarg [ 19/Nov/08 10:50 AM ]

I am solely using a mail session created using GlassFish Admin GUI as a resource
and enabled debugging in the admin GUI by clicking the check box. I am neither
creating my own mail session by API, nor am I enabling debugging by API. My code
does nothing with the JavaMail API but just ask the injected javax.mail.Session
to create a Message object, set subject, sender, receiver and body, and then
call Transport.send(message). Nothing more.

So I assume it is a bug in the GlassFish code that links JavaMail to the

Comment by mkarg [ 27/Apr/09 11:55 PM ]

Increased priority to P3 according to
https://glassfish.dev.java.net/public/IssueTrackerPriority.html as this bug is
neither internal nor invisible. It leads to squandered time and money for the
administrator. From an economic view this is not acceptable in a production

Comment by peterwx [ 22/Jun/09 04:49 PM ]

V3 uses MailLogOutputStream and most JavaMail log messages are printed at FINE
in that server. However, the first 5 or so messages are printed to the console.

This is because they are printed in the javax.mail.Session constructor and V3
doesn't redirect the debug output until after Session construction is finished.
Log output looks like this:

INFO: DEBUG: JavaMail version 1.4.2
INFO: DEBUG: successfully loaded resource: /META-INF/javamail.default.providers
INFO: DEBUG: Tables of loaded providers
INFO: DEBUG: Providers Listed By Class Name: ...
INFO: DEBUG: Providers Listed By Protocol: ...
INFO: DEBUG: successfully loaded resource: /META-INF/javamail.default.address.map
FINE: DEBUG: setDebug: JavaMail version 1.4.2
FINE: DEBUG: getProvider() returning
Microsystems, Inc]
FINE: DEBUG SMTP: useEhlo true, useAuth true

Comment by peterwx [ 22/Jun/09 05:25 PM ]

V2.1 behaves similarly – initial messages (from javax.mail.Session constructor)
are printed to the console. All subsequent messages are printed at FINE level.

Annoying, but not as widespread as hinted at. Note this can still print quite a
bit of information in production as mail sessions could be created quite
frequently. This depends on user's application, but a mail session object could
conceivably be created fresh for each usage of javamail.

Comment by peterwx [ 06/Jul/09 07:18 PM ]

I'm lowering this to P4 based on the following reasons:

The only messages written to the console by JavaMail (and thus logged at INFO
level) are debug messages from the javax.mail.Session constructor (and possibly
other messages logged during session construction or requisite static

Further, this only happens if debug=true (or the properly "mail.debug=true") has
been set in the mail resource.

Once the mail session has been constructed, all subsequent mail debug messages
will be logged at FINE or FINER as designed.

The correct way to enable JavaMail debug messages in GlassFish is to set the
GlassFish JavaMail log level to the appropriate setting for the domain
configuration in question. There is a setting for this in the web based admin
console or you can use asadmin.

Do not set debug=true or add a "mail.debug=true" property in the mail resource
unless you specifically want debug messages from session construction
(occasionally useful, but not typically).

Comment by Bill Shannon [ 04/Nov/09 02:29 PM ]

The full fix for this will only come when JavaMail is converted to
use java.util.logging directly.

Generated at Thu Apr 24 07:37:10 UTC 2014 using JIRA 4.0.2#472.