Re: JavaMail bug?

On Mon, 25 Jul 2011 20:11:31 +0000, Martin Gregorie wrote:


Sorted. Now back the the JavaMail problem:

I modified the TestMail SSCE to suit my environment by changing the
'mail.smtp.host' property to "ukfsn.org" (my ISP) and the transport
connect statement became

    tr.connect("zoogz.gregorie.org", "kiwi", "n/a")

This works regardless of whether the local MTA is running or stopped.

Then I made my own SSCE, MATestMail, from code in my mail dispatch class.
The only differences between my SSCE and TestMail are that it does not
add the 'mail.smtp.host' property to system props and it gets the session
with "Session.getInstance(props)" rather than "Session.getDefaultInstance
(props, null)".

It also creates and sends a message to myself so the headers can be seen
and I added a quick and dirty hack to optionally turn on SMTP debugging.
Both turned out to be useful for working out exactly what was going on.

The 'gotcha' turned out to be my omission to set the 'mail.smtp.host'
property. I didn't do that because the connect() documentation says that
it overrides the default host. This turns out to be incorrect: the MTA
host named in connect() appears in all the debugging and is used by the
getURL method, *but* the hostname supplied in the 'mail.smtp.host'
property is what defines the MTA that is actually used. If the property
is omitted the MTA host name defaults to localhost.

When I added that property and messed about with its value I found the
following behaviour, which was clearly shown by looking at the test
message headers and the /var/log/maillog on zoogz:

- With the 'mail.smtp.host' property unset the local MTA is always used:
  if its running the message is sent via 'localhost' and if it is stopped
  JavaMail reports a connection failure.

- With it set to 'mail.ukfsn.org' the mail went via my ISP's mail server.

- With it set to 'zoogz.gregorie.org' the mail is sent directly to zoogz.

During all three property values the connect() method was using
"zoogz.gregorie.org" as the 'host' parameter.

For completeness, here's my SSCE:

import java.util.Date;
import java.util.Properties;
import javax.mail.*;
import javax.mail.internet.*;

public class MATestMail
{
   public static void main(String args[])
   {
      String host = "zoogz.gregorie.org";
      String user = "kiwi";
      String password = "n/a";
      String to = "martin@gregorie.org";
      String from = "ma@gregorie.org";
      String subject = "Test message";
      boolean debug = true;
      Session sesh;

      try
      {
         Properties props = System.getProperties();

         sesh = Session.getInstance(props);
         if (args.length > 0)
            sesh.setDebug(debug);
      
         MimeMessage msg = new MimeMessage(sesh);
         MimeMultipart body = new MimeMultipart();
         InternetAddress[] recipients = {new InternetAddress(to)};
         InternetAddress sender = new InternetAddress(from);
         msg.setFrom(sender);
         msg.setRecipients(Message.RecipientType.TO, recipients);
         msg.setSubject(subject);
         msg.setSentDate(new Date());
         MimeBodyPart b = new MimeBodyPart();
         b.setText("This is an SSCE test message\n");
         body.addBodyPart(b);
         msg.setContent(body);
         msg.saveChanges();

         Transport tr = sesh.getTransport("smtp");
         tr.connect(host, user, password);
         System.out.println(tr);
         System.out.println(tr.getURLName());
         tr.send(msg);
         tr.close();
      }
      catch(MessagingException e)
      {
         e.printStackTrace();
      }
   }
}

This SSCE doesn't set 'mail.smtp.host' and so will fail if the localhost
MTA isn't running: I develop on a Linux box, so there's always a local
MTA - hence the comment about the localhost MTA not running rather than
it not existing.

To make this SSCE connect directly to the target MTA (zoogz) I added the
statement:

    props.put("mail.smtp.host", "zoogz.gregorie.org");

immediately after the 'Properties props = System.getProperties();'
statement.

The description of Transport.connect(host, user, password) is not at all
clearly written, but having read it and the description of
Transport.connect(user, password) I still think it means that the values
supplied as connect() parameters should take precedence over those set
via the property system, however connect() is plainly written to do the
opposite, leaving me to wonder why connect(host, user, password) even
exists.

So, what do you think: have I found a bug?

Many thanks to Nigel and Knute for helpful suggestions and example code.

--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |