In many of its activities, the JavaMail API needs to access certain configuration
files. The JavaMail and JavaBeans Activation Framework binary packages themselves
already contain the necessary configuration files. However, the JavaMail API
allows the user to define user-specific and installation-specific configuration
files to meet special requirements.
The two locations where such configuration files can exist are
<user.home>and
<java.home>/lib.
For example, if the JavaMail API needs to access a file named
mailcap when
sending a message, it first tries to access
<user.home>/.mailcap.
If that attempt fails, either due to lack of security permission or a nonexistent
file, the API continues to try
<java.home> /lib/mailcap. If
that attempts also fails, it tries META-INF/mailcap in the class path,
which actually leads to the configuration files contained in the
mail.jar and
activation.jar files.
WebSphere Application Server uses the general-purpose JavaMail configuration
files contained in the
mail.jar and
activation.jar files
and does not put any mail configuration files in
<user.home>and
<java.home>/lib.
File read permission for both the
mail.jar and
activation.jar files
is granted to all applications to ensure proper functioning of the JavaMail
API, as shown in the following segment of the
app.policy file:
grant codeBase "file:${application}" {
// The following are required by Java mail
permission java.io.FilePermission "${was.install.root}${/}java${/}jre${/}lib${/}ext${/}mail.jar", "read";
permission java.io.FilePermission "${was.install.root}${/}java${/}jre${/}lib${/}ext${/}activation.jar", "read";
};
JavaMail code attempts to access configuration files at
<user.home>and
<java.home>/lib causing
AccessControlExceptions to be thrown, since there is no file read permission granted for those two
locations by default. This activity does not affect the proper functioning
of the JavaMail API, but you might see a large amount of JavaMail-related
security exceptions reported in the system log, which might swamp harmful
errors that you are looking for. If this situation is a problem, consider
adding two more permission lines to the permission block above. This should
eliminate most, if not all, JavaMail-related harmless security exceptions
from the log file. The application permission block in the
app.policy file
now looks like:
grant codeBase "file:${application}" {
// The following are required by Java mail
permission java.io.FilePermission "${was.install.root}${/}java${/}jre${/}lib${/}ext${/}mail.jar", "read";
permission java.io.FilePermission "${was.install.root}${/}java${/}jre${/}lib${/}ext${/}activation.jar", "read";
permission java.io.FilePermission "${user.home}${/}.mailcap", "read";
permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read";
};