JavaMail bug?
Martin Gregorie
If I try to open an SMTP connection by obtaining a transport instance
and then calling connect():
Transport tr = sesh.getTransport("smtp");
tr.connect(host, user, password);
where:
sesh is the current mail session,
host is "zoogz.gregorie.org"
user is "kiwi"
and password is a valid password for the user
Transport.connect() sets up the URLName "smtp://ki...@zoogz.gregorie.org",
which is what I expect, but then promptly fails with:
javax.mail.MessagingException:
Could not connect to SMTP host: localhost, port: 25;
nested exception is:
java.net.ConnectException: Connection refused
when the local Postfix MTA on the machine I'm connecting from
(zappa.gregorie.org) is stopped.
If I restart the local Postfix instance the connect request succeeds and
the mail message is sent, but its headers clearly show that JavaMail
delivered it to the local MTA, which then passed it to the Postfix MTA on
zoogz.gregorie.org, which has been listening on port 25 the whole time.
IOW the Transport.connect(host,user,password) method sets up its target
URL as expected but then promptly ignores it and defaults to connecting
to localhost on port 25.
Have any of you seen this problem?
Have I done anything stupid?
Is there a workround?
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Knute Johnson
The last time I used JavaMail I set it up differently with properties
and MimeMessages so I didn't use quite the same method as you did to
send. That's one of the problems with JM, you can get at the problem
from about 50 different ways. If you want to write a little simple test
program, I'll try it here. I've got mail servers I can test it on
although I don't have the host names with quite the same organization.
There wouldn't be MX records on the DNS for zoogz would there?
--
Knute Johnson
Martin Gregorie
> The last time I used JavaMail I set it up differently with properties
> and MimeMessages so I didn't use quite the same method as you did to
> send. That's one of the problems with JM, you can get at the problem
> from about 50 different ways. If you want to write a little simple test
> program, I'll try it here. I've got mail servers I can test it on
> although I don't have the host names with quite the same organization.
>
Thanks. I'll put together a suitably parameterised test program over the
next day few days (it looks like soarable weather in the first half of
the week - something that's been all too rare recently to miss for
anything).
> There wouldn't be MX records on the DNS for zoogz would there?
>
Yes - I run a local DNS to handle names within my LAN and there is an MX
record for zoogz.
Knute Johnson
And it's pointing in the right place?
I just found out yesterday that my old friend Ron Gregg is running the
soaring operation at Crystallaire again. I towed gliders and flight
instructed for him in the late 70s. I've got to go out there and see
him and do some soaring this summer. I'm off to Las Vegas today to
install some software but maybe next week.
--
Knute Johnson
Nigel Wade
That certainly seems to be the problem. The MessagingException shows
it's failing to connect to localhost.
> Have any of you seen this problem?
No, mine works as expected. At least, when I attempt a simple
Transport.connect(host, user, pwd) it connects to my SMTP server on port
25. It doesn't authenticate because my SMTP server doesn't offer AUTH on
port 25. But it does connect to the correct host.
> Have I done anything stupid?
Hard to say with the limited code you've provided.
This is the code I'm testing with.
import java.util.Properties;
import javax.mail.Message;
import javax.mail.MessagingException;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.AddressException;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;
public class TestMail {
static String SMTP_SERVER = "yahoo.com";
public static void main(String[] args) {
// Get system properties
Properties props = System.getProperties();
// Setup mail server
props.put("mail.smtp.host", SMTP_SERVER);
// Get session
Session session = Session.getDefaultInstance(props, null);
try {
Transport tr = session.getTransport("smtp");
tr.connect("mail.ion.le.ac.uk", "user", "password");
System.out.println(tr);
System.out.println(tr.getURLName());
}
catch(MessagingException e) {
e.printStackTrace();
}
}
}
The value of the parameter host to connect() is overriding that set in
the Properties, which the correct behaviour. The URL output is:
smtp://us...@mail.ion.le.ac.uk
I see the connection on mail.ion.le.ac.uk, and the SMTP handshake, using
Wireshark.
My guess is that there's a mistake somewhere in the code you haven't
shown us yet.
BTW, what version of JavaMail are you using? I've tested the above code
with both 1.3.1 and 1.4.4.
--
Nigel Wade
Martin Gregorie
> On 7/24/2011 2:50 AM, Martin Gregorie wrote:
>> Yes - I run a local DNS to handle names within my LAN and there is an
>> MX record for zoogz.
>
> And it's pointing in the right place?
>
Yes. I use Evolution on 'zappa' for general mail access. It is configured
to send mail to zoogz via SMTP and to get incoming mail from 'zoogz' via
a Dovecot POP3 server. This works regardless of whether the 'zappa' MTA
is running or not and, unlike the messages sent via JavaMail, *doesnt*
have a Received: header for 'zappa'.
> I just found out yesterday that my old friend Ron Gregg is running the
> soaring operation at Crystallaire again. I towed gliders and flight
> instructed for him in the late 70s. I've got to go out there and see
> him and do some soaring this summer.
>
Where does Crystallaire fly out of? Its not a name I know.
Martin Gregorie
> This is the code I'm testing with.
>
Thanks (test code snipped).
I'll compile and run that as well as extracting an SSCE from my own code.
> My guess is that there's a mistake somewhere in the code you haven't
> shown us yet.
>
Possibly. On a quick look everything within the try/catch bolck looks
like what I'm going but I'm less certain that there are no differences in
the preceeding code that's getting hold of the Session.
> BTW, what version of JavaMail are you using? I've tested the above code
> with both 1.3.1 and 1.4.4.
>
I first noticed it with JavaMail 1.4.3. Since I noticed the problem I've
installed 1.4.4 and *think* I've been running against it. I said 'think'
because the JavaMail jar is called mail.jar in both versions and, as I
didn't reboot the machine or logout between nominal 1.4.3 and 1.4.4 tests
I'm not 100% sure that the later jar file got loaded.
Is there anything I can do to check which jar file is loaded, i.e. are
there any distinguishing marks inside the jar file that would tell me
which is loaded?
Martin Gregorie
> On Mon, 25 Jul 2011 15:40:44 +0100, Nigel Wade wrote:
>
>> This is the code I'm testing with.
>>
> Thanks (test code snipped).
>
> I'll compile and run that as well as extracting an SSCE from my own
> code.
>
I meant to add that I'm sorting out a bit of C at present. Running your
test program and extracting my SSCE it on the list behind it.
Knute Johnson
> Where does Crystallaire fly out of? Its not a name I know.
Crystallaire is in Pearblossom, just a few miles southeast of Palmdale.
I met my wife there in 1976, she was one of my students.
--
Knute Johnson
s/knute/nospam/
Steve Sobol
>
> On 7/25/2011 12:36 PM, Martin Gregorie wrote:
> > Where does Crystallaire fly out of? Its not a name I know.
>
> Crystallaire is in Pearblossom, just a few miles southeast of Palmdale.
> I met my wife there in 1976, she was one of my students.
Uh, what? I always thought Pearblossom was just a small patch of empty
land :)
--
Steve Sobol - Programming/WebDev/IT Support
sjs...@JustThe.net
Martin Gregorie
> On 7/25/2011 12:36 PM, Martin Gregorie wrote:
>> Where does Crystallaire fly out of? Its not a name I know.
>
> Crystallaire is in Pearblossom, just a few miles southeast of Palmdale.
> I met my wife there in 1976, she was one of my students.
Gotcha. Google Earth finds all.
Martin Gregorie
> In article <YJsXp.28709$tp....@newsfe06.iad>, Knute Johnson says...
>>
>> On 7/25/2011 12:36 PM, Martin Gregorie wrote:
>> > Where does Crystallaire fly out of? Its not a name I know.
>>
>> Crystallaire is in Pearblossom, just a few miles southeast of Palmdale.
>> I met my wife there in 1976, she was one of my students.
>
> Uh, what? I always thought Pearblossom was just a small patch of empty
> land :)
>
The airfield is called Crystal, a few miles east of Pearblossom on the
far side of the river - follow the Pearblossom Highway until it crosses
the river and take the first turn south on 165 East. There's a trailer
park right next to it that makes Pearblossom look like paradise.
Martin Gregorie
> I meant to add that I'm sorting out a bit of C at present. Running your
> test program and extracting my SSCE it on the list behind it.
>
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 = "mar...@gregorie.org";
String from = "m...@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.
Knute Johnson
Looks like a bug to me. I tried to search the Sun bug list but it isn't
working today. I also looked around the Internet but didn't see
anything there either. I'd try to file a bug report.
--
Knute Johnson
Nigel Wade
> 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
> property is what defines the MTA that is actually used. If the property
> is omitted the MTA host name defaults to localhost.
That is in conflict with my findings.
If you look at the message I posted, with the code I sent, you'll see
that I set mail.smtp.host to yahoo.com. However, in Transport.connect()
I explicitly connect to our mail server, overriding the value in the
mail.smtp.host property. This worked for me, as I mentioned in the post.
If I comment out that line, so mail.smtp.host is unset, it still
connects to our mail server as per the Transport.connect() host setting.
What does my code do if you run it exactly as is? Does it attempt to
connect to yahoo.com or our mail server (you won't actually be able to
connect, it's blocked on port 25)?
--
Nigel Wade
Andreas Leitgeb
> 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.
Fwiw: I recently saw this kind of behaviour on Oracle on a Solaris host:
Some mailhost is configured for "smtp_out_server", which is supposed to
be used for utl_mail (pl/sql), but is also used for utl_smtp (ignoring
the hostname passed to utl_smtp.Open_Connection(...).)
I haven't used JavaMail myself, so can't say much about that.
Martin Gregorie
> What does my code do if you run it exactly as is? Does it attempt to
> connect to yahoo.com or our mail server (you won't actually be able to
> connect, it's blocked on port 25)?
>
It fails connecting to your server.
So, where does THAT leave us? The only difference is that you call
getDefaultInstance(props) while I call getInstance(props) and, according
to the documentation, these should do exactly the same the first time
they're called.
BTW, I added the single property setting line to my application code so
that it uses the same hostname for 'mail.smtp.host' as connect(host,
user, passwd) does. That code now connects directly to the expected
server.
What does my SSCE do in your environment?
Do please post a response, but be aware that I'm unlikely to read it
until next week.
Nigel Wade
> On Mon, 01 Aug 2011 13:20:09 +0100, Nigel Wade wrote:
>
>> What does my code do if you run it exactly as is? Does it attempt to
>> connect to yahoo.com or our mail server (you won't actually be able to
>> connect, it's blocked on port 25)?
>>
> It fails connecting to your server.
Yes, well, that's what I said would happen.
>
> So, where does THAT leave us?
With the fact that it /attempted/ to connect to our mail server - not
localhost, and not yahoo.com.
> The only difference is that you call
> getDefaultInstance(props) while I call getInstance(props) and, according
> to the documentation, these should do exactly the same the first time
> they're called.
I see the same behaviour with either getDefaultInstance() or
getInstance() - it connects to our mail server.
>
> BTW, I added the single property setting line to my application code so
> that it uses the same hostname for 'mail.smtp.host' as connect(host,
> user, passwd) does. That code now connects directly to the expected
> server.
>
> What does my SSCE do in your environment?
I get:
javax.mail.MessagingException: Unknown SMTP host: zoogz.gregorie.org;
nested exception is:
java.net.UnknownHostException: zoogz.gregorie.org
I presume your DNS does not propagate upward from your zone. But it /is/
attempting to resolve that hostname via our DNS servers. It's not using
localhost.
--
Nigel Wade
Martin Gregorie
>> What does my SSCE do in your environment?
>
> I get:
>
> javax.mail.MessagingException: Unknown SMTP host: zoogz.gregorie.org;
> nested exception is:
> java.net.UnknownHostException: zoogz.gregorie.org
>
> I presume your DNS does not propagate upward from your zone.
>
Correct. Its definitive only within my LAN and my firewall refused all
connections from outside.
> But it /is/ attempting to resolve that hostname via our DNS servers.
> It's not using localhost.
>
Interesting. I wonder why we're seeing a difference.
I assume you ran it with no command line arguments except (possibly)
'debug'.
When I do that the debugging text says that it was trying to connect to
zoogz.gregorie.org. Lines 7 and 8 show the first 220 followed a DEBUG
line reporting this. Then lines 31 and 32 report a failure to connect to
localhost and the resulting exception. If you're following this with
Wireshark I'd expect you to see the first connect attempt but maybe not
the second. Here's the debugging output:
$ java MATestMail debug
DEBUG: setDebug: JavaMail version 1.4.4
DEBUG: getProvider() returning javax.mail.Provider
[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]
DEBUG SMTP: useEhlo true, useAuth false
DEBUG SMTP: trying to connect to host "zoogz.gregorie.org", port 25, isSSL
false
220 zoogz.gregorie.org ESMTP Postfix
DEBUG SMTP: connected to host "zoogz.gregorie.org", port: 25
EHLO zappa.gregorie.org
250-zoogz.gregorie.org
250-PIPELINING
250-SIZE 51200000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
DEBUG SMTP: Found extension "PIPELINING", arg ""
DEBUG SMTP: Found extension "SIZE", arg "51200000"
DEBUG SMTP: Found extension "VRFY", arg ""
DEBUG SMTP: Found extension "ETRN", arg ""
DEBUG SMTP: Found extension "ENHANCEDSTATUSCODES", arg ""
DEBUG SMTP: Found extension "8BITMIME", arg ""
DEBUG SMTP: Found extension "DSN", arg ""
smtp://ki...@zoogz.gregorie.org
smtp://ki...@zoogz.gregorie.org
DEBUG: getProvider() returning javax.mail.Provider
[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]
DEBUG SMTP: useEhlo true, useAuth false
DEBUG SMTP: trying to connect to host "localhost", port 25, isSSL false
javax.mail.MessagingException: Could not connect to SMTP host: localhost,
port: 25;
nested exception is:
java.net.ConnectException: Connection refused
at com.sun.mail.smtp.SMTPTransport.openServer
(SMTPTransport.java:1934)
at com.sun.mail.smtp.SMTPTransport.protocolConnect
(SMTPTransport.java:638)
at javax.mail.Service.connect(Service.java:295)
at javax.mail.Service.connect(Service.java:176)
at javax.mail.Service.connect(Service.java:125)
at javax.mail.Transport.send0(Transport.java:194)
at javax.mail.Transport.send(Transport.java:124)
at MATestMail.main(MATestMail.java:59)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress
(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at com.sun.mail.util.SocketFetcher.createSocket
(SocketFetcher.java:288)
at com.sun.mail.util.SocketFetcher.getSocket
(SocketFetcher.java:231)
at com.sun.mail.smtp.SMTPTransport.openServer
(SMTPTransport.java:1900)
... 7 more
At this point I really am going to drop off the net for a few days - got
a 5AM start tomorrow.
Nigel Wade
> On Tue, 02 Aug 2011 16:34:20 +0100, Nigel Wade wrote:
>
>>> What does my SSCE do in your environment?
>>
>> I get:
>>
>> javax.mail.MessagingException: Unknown SMTP host: zoogz.gregorie.org;
>> nested exception is:
>> java.net.UnknownHostException: zoogz.gregorie.org
>>
>> I presume your DNS does not propagate upward from your zone.
>>
> Correct. Its definitive only within my LAN and my firewall refused all
> connections from outside.
>
>> But it /is/ attempting to resolve that hostname via our DNS servers.
>> It's not using localhost.
>>
> Interesting. I wonder why we're seeing a difference.
> I assume you ran it with no command line arguments except (possibly)
> 'debug'.
I doubt it would help. Since the host doesn't resolve, there's really
nothing to debug. It can't connect to anything because it has no IP for
the connect.
>
> When I do that the debugging text says that it was trying to connect to
> zoogz.gregorie.org. Lines 7 and 8 show the first 220 followed a DEBUG
> line reporting this. Then lines 31 and 32 report a failure to connect to
> localhost and the resulting exception. If you're following this with
> Wireshark I'd expect you to see the first connect attempt but maybe not
> the second. Here's the debugging output:
>
> $ java MATestMail debug
> DEBUG: setDebug: JavaMail version 1.4.4
> DEBUG: getProvider() returning javax.mail.Provider
> [TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]
> DEBUG SMTP: useEhlo true, useAuth false
> DEBUG SMTP: trying to connect to host "zoogz.gregorie.org", port 25, isSSL
> false
> 220 zoogz.gregorie.org ESMTP Postfix
> DEBUG SMTP: connected to host "zoogz.gregorie.org", port: 25
Here, you have connected to your mail server zoogz.gregorie.org
>
> EHLO zappa.gregorie.org
> 250-zoogz.gregorie.org
> 250-PIPELINING
> 250-SIZE 51200000
> 250-VRFY
> 250-ETRN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
and received the standard mail server 250 connection response.
Note that it does not include AUTH, so no authentication will be allowed
and the client should not attempt it.
> DEBUG SMTP: Found extension "PIPELINING", arg ""
> DEBUG SMTP: Found extension "SIZE", arg "51200000"
> DEBUG SMTP: Found extension "VRFY", arg ""
This isn't a good idea. It's an open invitation to spammers to verify
the existence of every recipient in your domain.
> DEBUG SMTP: Found extension "ETRN", arg ""
> DEBUG SMTP: Found extension "ENHANCEDSTATUSCODES", arg ""
> DEBUG SMTP: Found extension "8BITMIME", arg ""
> DEBUG SMTP: Found extension "DSN", arg ""
> smtp://ki...@zoogz.gregorie.org
> smtp://ki...@zoogz.gregorie.org
> DEBUG: getProvider() returning javax.mail.Provider
> [TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]
> DEBUG SMTP: useEhlo true, useAuth false
> DEBUG SMTP: trying to connect to host "localhost", port 25, isSSL false
I presume that this is due to the fact that the connect() above failed.
You have specified authentication by using a user/password, but the
connection does not allow authentication. When you subsequently use
tr.send() there is no open session so a default session is created which
appears to be to localhost.
Nigel Wade
it. You need to be aware that Transport.send() is a /static/ method. I
presume this means it takes no note of any connection established by an
object of class Transport, since the class method has no knowledge of
any contents of any Transport object. That probably explains why it uses
the values in the Session, not those established by the Transport object
you've created.
--
Nigel Wade
Martin Gregorie
> Note that it does not include AUTH, so no authentication will be allowed
> and the client should not attempt it.
>
Fair point.
> This isn't a good idea. It's an open invitation to spammers to verify
> the existence of every recipient in your domain.
>
Except that this server really is private: my firewall blocks all inbound
connection requests and so its only contact with the outside world are
its outbound SMTP connections to my ISP's mail server when it needs to
send mail. Incoming mail is fetched by getmail and passed to the MTA via
the Postfix.sendmail utility.
> I presume that this is due to the fact that the connect() above failed.
> You have specified authentication by using a user/password, but the
> connection does not allow authentication. When you subsequently use
> tr.send() there is no open session so a default session is created which
> appears to be to localhost.
>
OK, that makes sense.
Your point about Transport.send() being static would seem to explain the
behaviour I'm seeing, but there's still a heap of anomalies, mainly in
the documentation:
- Transport.send() says that its not a good idea to inherit the
connection from a Session and doesn't provide a suitable way of setting
the hostname (at least its docs don't mention one or mention the use of
properties, though obviously they are used by it.
- now go and look at SMTPTransport. Its documentation includes
example code doing as we did, and getting the connection from Session.
Gaargh!
The double connect is now explained by the Session.connect() making one
connection and Transport.send() making a second
Nigel Wade
> On Wed, 03 Aug 2011 09:27:43 +0100, Nigel Wade wrote:
>
>> Note that it does not include AUTH, so no authentication will be allowed
>> and the client should not attempt it.
>>
> Fair point.
>
>> This isn't a good idea. It's an open invitation to spammers to verify
>> the existence of every recipient in your domain.
>>
> Except that this server really is private: my firewall blocks all inbound
> connection requests and so its only contact with the outside world are
> its outbound SMTP connections to my ISP's mail server when it needs to
> send mail. Incoming mail is fetched by getmail and passed to the MTA via
> the Postfix.sendmail utility.
Ok. Fairy snuff.
Personally I'd still get rid of it unless you are actively using it.
It's somewhat in the realm of "security by obscurity". There's a potential for the vulnerability to be exposed, or for the configuration to migrate somewhere where it is exposed. Imagine your firewall goes down, the mail server stops working and users are clamouring for their email (it's like a drug here, users will get along without any other system, but not the mail server). Panic, Panic. Bypass the broken firewall to get the mail server back online - and now you're exposed.
>
>> I presume that this is due to the fact that the connect() above failed.
>> You have specified authentication by using a user/password, but the
>> connection does not allow authentication. When you subsequently use
>> tr.send() there is no open session so a default session is created which
>> appears to be to localhost.
>>
> OK, that makes sense.
>
> Your point about Transport.send() being static would seem to explain the
> behaviour I'm seeing, but there's still a heap of anomalies, mainly in
> the documentation:
>
> - Transport.send() says that its not a good idea to inherit the
> connection from a Session and doesn't provide a suitable way of setting
> the hostname (at least its docs don't mention one or mention the use of
> properties, though obviously they are used by it.
>
> - now go and look at SMTPTransport. Its documentation includes
> example code doing as we did, and getting the connection from Session.
>
I see the documentation showing use of Transport.sendMessage() (an abstract
instance method) following a Session.getTransport().
I don't see use of Transport.send().
--
Nigel Wade
Martin Gregorie
> Personally I'd still get rid of it unless you are actively using it.
> It's somewhat in the realm of "security by obscurity". There's a
> potential for the vulnerability to be exposed, or for the configuration
> to migrate somewhere where it is exposed.
>
Its unlikely that anything like that would happen. This is my house
server that I'm describing. The config is whatever I set it to and nobody
else is ever likely to touch it.
> Imagine your firewall goes
> down, the mail server stops working
>
Indeed. If the firewall breaks, nothing will work until it gets replaced.
> I see the documentation showing use of Transport.sendMessage() (an
> abstract instance method) following a Session.getTransport().
>
Sure, but they are all static apart from sendMessage, which is abstract.
> I don't see use of Transport.send().
>
True enough.
Nigel Wade
> On Tue, 09 Aug 2011 13:31:49 +0100, Nigel Wade wrote:
>
>> I see the documentation showing use of Transport.sendMessage() (an
>> abstract instance method) following a Session.getTransport().
>>
> Sure, but they are all static apart from sendMessage, which is abstract.
It's sendMessage() which they use in the example, not any of the static
methods - that's the important fact. sendMessage() must be implemented
by whatever class creates the Transport which is returned by
Session.getTransport(), it could not instantiate a Transport unless it
had implemented the abstract methods.
--
Nigel Wade
Martin Gregorie
> It's sendMessage() which they use in the example, not any of the static
> methods - that's the important fact. sendMessage() must be implemented
> by whatever class creates the Transport which is returned by
> Session.getTransport(), it could not instantiate a Transport unless it
> had implemented the abstract methods.
>
Thanks for the reminder. I was knackered last night due to having flown a
4 1/4 hour soaring flight yesterday PM and that didn't register.
I still think we're dealing with an ugly bit of design, though: IMO there
too many ways of specifying the MTA host and login parameters and, worse,
the design decision to use static methods has prevented these from being
orthogonal to the methods that send messages.
Martin Gregorie
Final comment:
On Sunday this whole mess niggled me again, so I ripped out the property
setting the default MTAname and replaced the call of tr.send(msg) with
tr.sendMessage(msg, recipients) so the Transport acquired from the
Session is used. This all works as expected: there's only the one EHLO
conversation and the recipient is validated (which I don't remember
seeing earlier).
Nigel Wade
Yes, I think that's the best way to do authentication. If you look at
the top of the Javadocs for com.sun.mail.smtp (the protocol which is
actually used behind the scenes, it's not exactly obvious because the
design hides this from you) it states:
To use SMTP authentication you'll need to set the mail.smtp.auth
property (see below) or provide the SMTP Transport with a username and
password when connecting to the SMTP server. You can do this using one
of the following approaches:
* Provide an Authenticator object when creating your mail Session
and provide the username and password information during the
Authenticator callback.
Note that the mail.smtp.user property can be set to provide a
default username for the callback, but the password will still need to
be supplied explicitly.
This approach allows you to use the static Transport send method
to send messages.
* Call the Transport connect method explicitly with username and
password arguments.
This approach requires you to explicitly manage a Transport
object and use the Transport sendMessage method to send the message. The
transport.java demo program demonstrates how to manage a Transport
object. The following is roughly equivalent to the static Transport send
method, but supplies the needed username and password:
Transport tr = session.getTransport("smtp");
tr.connect(smtphost, username, password);
msg.saveChanges(); // don't forget this
tr.sendMessage(msg, msg.getAllRecipients());
tr.close();
--
Nigel Wade
Martin Gregorie
Yes, I found that too.
> Transport tr = session.getTransport("smtp");
> tr.connect(smtphost, username, password); msg.saveChanges();
> // don't forget this tr.sendMessage(msg,
> msg.getAllRecipients());
> tr.close();
>
I'm not calling Message.saveChanges(), but as something wrapped your text
up in a bit of a ball I'm not sure that your 'don't forget' refers to.
Instead I hung onto the recipient array and just passed it into
Transport.sendMessage(). It also works correctly.
Nigel Wade
>>
> I'm not calling Message.saveChanges(), but as something wrapped your text
> up in a bit of a ball I'm not sure that your 'don't forget' refers to.
> Instead I hung onto the recipient array and just passed it into
> Transport.sendMessage(). It also works correctly.
>
It isn't "mine". It's a quote from the Javadocs. It refers to the
saveMessage(), which I've never used. I presume that's in case you want
to save the changes to the messages into some message store (Drafts?).
The entire package is rather convoluted for simple message
generation/submission.
I don't know why you don't see the text correctly. The post appears ok
viewed in my newsreader (Thunderbird). It's flowed text, maybe your
newsreader doesn't like that. But, as far as I can tell, the code part
is correctly line-wrapped anyway, rather than flowed.
--
Nigel Wade
Martin Gregorie
> It isn't "mine". It's a quote from the Javadocs. It refers to the
> saveMessage(), which I've never used.
>
Thanks for the clarification.
> I presume that's in case you want
> to save the changes to the messages into some message store (Drafts?).
>
Thats what the method description says its for.
> The entire package is rather convoluted for simple message
> generation/submission.
>
It certainly gives me the impression of having been written before it was
designed or documented and that it wasn't fully understood by the
documentation's author.
> I don't know why you don't see the text correctly. The post appears ok
> viewed in my newsreader (Thunderbird).
>
OK. I thought that finding "msg.saveMessage();" had been wrapped onto the
end of the preceding line since the rest of the snippet is one statement
per line. I've noticed that some constructions - particularly 'bulleted
points', i.e. lines each starting with '- ' tend to get wrapped by
something in USENET and thought this was another case of it.