2
votes

I have an email ssl client for zimbra mail server that work perfectly on windows but i got a failure authentication on linux, i had verified that all that network conf. dns, port and firewall are correct

the properties for session:

props.put("mail.smtps.host", "my.mail.server");
props.put("mail.smtps.host", "my.mail.server");
props.put("mail.smtps.starttls.enable", "true");
props.put("mail.smtps.port", "465");
props.put("mail.smtps.auth", "true");
props.put("mail.smtps.ssl.trust", "my.mail.server");

Getting the session:

Session session = Session.getDefaultInstance(props);

Transport :

Transport t = session.getTransport("smtps");
t.connect("user", "pass");
t.sendMessage(message, message.getAllRecipients());

something that got my attention when using debug, is the postfix response in the message

Windows Debug Log:

DEBUG: setDebug: JavaMail version 1.4.3 DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun Microsystems, Inc] DEBUG SMTP: useEhlo true, useAuth true DEBUG SMTP: trying to connect to host "my.mail.server", port 465, isSSL true 220 my.mail.server ESMTP ready. DEBUG SMTP: connected to host "my.mail.server", port: 465

meanwhile on Linux i got this:

DEBUG: setDebug: JavaMail version 1.4.3 DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun Microsystems, Inc] DEBUG SMTP: useEhlo true, useAuth true DEBUG SMTP: trying to connect to host "my.mail.server", port 465, isSSL true 220 my.mail.server ESMTP Postfix DEBUG SMTP: connected to host "my.mail.server", port: 465

i would appreciate any help.

2

2 Answers

1
votes

The difference in debug messages is not significant. It is just a cosmetic difference in what the two (local) mail servers put in their "connection greeting reply" line. For example, a Linux server that is running Postfix as its MTA will typically say:

220 smtp.example.com ESMTP Postfix

The ESMTP spec says:

"SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems. Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns."

The real problem will be something else.

If I was trying to debug this, I would start by looking at the MTA logs to see if they say why the session is being shut down. I would also check that the user / password are correct and that the MTA has been configured appropriately to allow what you are trying to do.

0
votes

I have found the issue, the server auth was different for local and external access, for development we were using a windows server outside the net, and linux server for intranet.

In fact, it was a misconfiguration on mail server

The java mail client remains the same now for local and public access.