Anthony Dahanne created NET-509:
-----------------------------------
Summary: AuthenticatingSMTPClient needs a constructor with the
isImplicit argument for SSL
Key: NET-509
URL: https://issues.apache.org/jira/browse/NET-509
Project: Commons Net
Issue Type: Bug
Components: SMTP
Environment: all
Reporter: Anthony Dahanne
AuthenticatingSMTPClient extends SMTPSClient but does not have a constructor
with the isImplicit argument.
Because of this we can not connect to a SSL SMTP server that requires
authentication.
According to the SMTPSClient javadoc :
{quote}
In explicit mode (the default), SSL/TLS
* negotiation starts when the user calls execTLS() and the server accepts the
command.
Implicit usage:
SMTPSClient c = new SMTPSClient(true);
c.connect("127.0.0.1", 465);
Explicit usage:
SMTPSClient c = new SMTPSClient();
c.connect("127.0.0.1", 25);
if (c.execTLS()) { /rest of the commands here/ }
{quote}
So all in all, we could think this is not important to have a constructor
without the isImplicit argument, since we can go the c.execTLS() way.
But here is what happens when you use the explicit usage with
AuthenticatingSMTPClient and a SSL connection (works fine with STARTTLS btw) :
when you call connect(), SMTP.__getReply() is eventually called, and line 196 :
{code}
String line = _reader.readLine();
{code}
is waiting for the SMTP server to reply... BUT the smtp client did not yet
initiate the SSL connection; so we just wait for the timeout to occur (since
the server won't reply anything before the SSL connection is initialized).
And if we try to call execTls() before connect(), we get a NPE because the
writer is not set yet.
I have attached a simple patch to make AuthenticatingSMTPClient works with SSL
connections (again it works fine with STARTTLS already)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
