You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Michael Kaegi <ka...@brainware.ch> on 2002/03/07 18:50:01 UTC

javax.mail.Session access protection

Hi 


How can I protect the JAMES javax.mail.Session? 
  
The problem is that my java application (or an other), which is on the 
same machine like JAMES, can access the JAMES javax.mail.Session. 
  
  
How? 
Session session = Session.getDefaultInstance(props, null); 
  
  
The JavaMail 1.2 Specification says in the chapter 5: The Mail Session: 
  
"The first call to the getDefaultInstance method creates a new Session 
object and associates it with the Authenticator object. Subsequent calls 
to the getDefaultInstance method compare the Authenticator object passed 
in with the Authenticator object saved in the default session. Access to 
the default session is allowed if both objects have been loaded by the 
same class loader. Typically, this is the case when both the default 
session creator and the program requesting default session access are in 
the same "security domain." Also, if both objects are null, access is 
allowed. Using null to gain access is discouraged, because this allows 
access to the 
default session from any security domain." 
  
I think "security domain" can mean JVM. 
  
My application requires JAMES therefore JAMES will be started first. 
=> The first call to the getDefaultInstance method creates a new Session 
object. 
Then my application will be started. 
=> Subsequent calls to the getDefaultInstance method get the default 
session from James if the authenticator is null. 
  
  
Now, how can I protect the JAMES javax.mail.Session? Or have I understood 
something completely wrong? Or is this a bug? 
  
Thanx, for your time? 
  
Bye 
Michi 

Re: javax.mail.Session access protection

Posted by Serge Knystautas <se...@lokitech.com>.
What default instance are you getting?  I don't think anything in James
would be using this... the only code that needs javax.mail.Session I believe
is the remote delivery thread, and it constructs separate Session objects
per delivery threads.  I assume this is some code in a mailet you're running
inside the James JVM... I'm not sure how you're allowing other people or
applications to run in the same JVM as James...

Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
----- Original Message -----
From: "Michael Kaegi" <ka...@brainware.ch>
To: <ja...@jakarta.apache.org>
Sent: Thursday, March 07, 2002 12:50 PM
Subject: javax.mail.Session access protection


Hi


How can I protect the JAMES javax.mail.Session?

The problem is that my java application (or an other), which is on the
same machine like JAMES, can access the JAMES javax.mail.Session.


How?
Session session = Session.getDefaultInstance(props, null);


The JavaMail 1.2 Specification says in the chapter 5: The Mail Session:

"The first call to the getDefaultInstance method creates a new Session
object and associates it with the Authenticator object. Subsequent calls
to the getDefaultInstance method compare the Authenticator object passed
in with the Authenticator object saved in the default session. Access to
the default session is allowed if both objects have been loaded by the
same class loader. Typically, this is the case when both the default
session creator and the program requesting default session access are in
the same "security domain." Also, if both objects are null, access is
allowed. Using null to gain access is discouraged, because this allows
access to the
default session from any security domain."

I think "security domain" can mean JVM.

My application requires JAMES therefore JAMES will be started first.
=> The first call to the getDefaultInstance method creates a new Session
object.
Then my application will be started.
=> Subsequent calls to the getDefaultInstance method get the default
session from James if the authenticator is null.


Now, how can I protect the JAMES javax.mail.Session? Or have I understood
something completely wrong? Or is this a bug?

Thanx, for your time?

Bye
Michi


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>