Gary Horton wrote:
> Thanks Sahoo for the pointer. You are correct, this is a necessary step.
> But, now I wonder how to get around an authentication issue - i.e. I
> receive messages like "530 5.7.0 No AUTH command has been given". To get
> around this, it appears I must use this type of approach (creating my
> own Session):
>
> Properties props = new Properties();
> props.put("mail.smtp.host", host);
> props.put("mail.smtp.auth", "true");
> Session sess = javax.mail.Session.getInstance(props, null);
> Message msg = new MimeMessage(sess);
> msg.setFrom(from);
> msg.setRecipients(Message.RecipientType.TO, to);
> msg.setSubject(subj);
> msg.setSentDate(new Date());
> msg.setText(body);
> Transport t = null;
> try {
> t = sess.getTransport("smtp");
> t.connect(user, password);
> t.sendMessage(msg, msg.getAllRecipients());
> this.logger.info("message sent!");
> } finally {
> t.close();
> }
>
> But this has two downsides, (1) I have to maintain and encrypt or
> otherwise protect the password and (2) now I'm not leveraging the
> container, I'm just using a standalone javamail session. Am I
> misunderstanding something?
Unfortunately, the integration between JavaMail and the container is
pretty weak. In particular, the container isn't going to help you
manage passwords for the mail servers you use.
You can do most of the configuration above in the JavaMail Session
resource you create using the admin GUI or CLI, then get the Session
from JNDI in the usual fashion, e.g., using injection. However, you
will have to make the connect call explicitly yourself, supplying the
username and password.
You could probably store the password in a keystore if that seems
more secure.