Page History

...

For mail configuration there are a number of screws that users can turn. It is important recommended to narrow down the problem in a systematic way:

• Follow the below steps in the given sequence.
• Do not turn too many screws at the same time. Instead, change one setting then check results by sending mail.
• Do not use mixed settings for different protocols. Instead, choose one protocol and apply settings recommended for that protocol only.

A larger number of e-mail settings is available, see https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html, however, in most cases they are not related to problems connecting to the a mail server.

Anchor
determine_protocol_port_usage determine_protocol_port_usage

Step 1: Determine Protocol and Port Usage

Mail servers frequently use specific ports per type of connection, however, protocol used with a connection. However, technically any port can be used. Your system administrator should provide the information about available protocols and ports:

...

Below examples check availability of TLS port 587, examples can similarly be applied with to SSL port 465:

# should telnet be available
telnet mail.example.com 587

# should nc or ncat be available
ncat -v -u mail.example.com 587

# should curl be available
curl --ssl --url mail.example.com:587

...

# test plain text port
curl --ssl --url mail.example.com:25

# output returned
#   can indicate that the port is not available:
#     curl: (7) Failed to connect to mail.example.com port 25 after 2186 ms: Connection refused
#   can indicate that the port is available: 
#     220 mail.example.com ESMTP Postfix (Debian/GNU)
#     221 2.7.0 Error: I can break rules, too. Goodbye.

# test SMTP over SSL
curl --ssl --url mail.example.com:465
# output returned can indicate that the port is available:
#   curl: (56) Recv failure: Connection reset by peer

# test SMTP over TLS
curl --ssl --url mail.example.com:587
# output returned can indicate that the port is not available:
#   curl: (7) Failed connect to mail.example.com:587; Connection refused

...

Depending on the Java version in use different defaults might be in place, therefore users should allow/deny use of SSL and /TLS:

...

Depending on the Java version in use different defaults might be in place, therefore users should allow/deny use of TLS/SSL and TLS:

...

Usually mail servers use certificates signed by well known certificate authorities who's Root CA Certificate is Certificates are included in distributions of OpenSSL and Java.

...

• JOC Cockpit: The protocol version is determined by the Java version and by the java.security file in place:
  
  • An older Java version 1.8 for example, can allow TLSv1 and TLSv1.1 SSL protocol versions that are considered outdated or insecure with the jdk8u202-b08/jre/lib/security/java.security file:
    • jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
      
      • TLSv1 and TLSv1.1 protocol versions are not disabled.
    • jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, 3DES_EDE_CBC, anon
      
      • A larger number of SSL protocol versions are disabled.
  • A newer Java version 17 for example, can disable SSL protocol versions that are considered outdated or insecure with the jdk-11.0.12+7/conf/security/java.security file.
    • jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
    DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
    include jdk.disabled.namedCurves
  • It is common practice that the Java versions available in an organization include adjusted copies of the java.security file that limit use of SSL protocol versions.
• Mail Server: For compatibility reasons they mail servers tend to support outdated or insecure protocol versions for a longer time.
  • There is not a simple way to determine all protocol versions supported by a mail server. Typically this requires SSL debugging, see Logging. The SSL debug log states the list of protocol versions offered by the client and by the mail server. If in doubt then your system administrator should know the mail server's supported protocol versions.

...

• The SSL protocol version in use determines available ciphers.
• The same ciphers have to be in place with the Java version used by the JOC Cockpit and with the mail server.
  • JOC Cockpit: Ciphers are determined by the Java version and the java.security file in place:
    • Older Java versions, for example 1.8, tend to allow ciphers that are considered outdated or insecure. If no recent updates to Java have been applied then newer ciphers might not be available.
    • Newer Java versions, for example 17, tend to disallow a number of ciphers that are considered outdated or insecure. 
  • Mail Server: There is not a simple way to determine all ciphers available with a mail server. Typically this requires SSL debugging, see Logging. The SSL debug log states the list of ciphers offered by the client and by the mail server.
  • Cipher mismatch is a possible source of error for example in the following situations:
    • An older Java version 1.8 (not recently updated) is used to connect to a mail server that is up-to-date when it comes to use of secure ciphers.
      • The mail server denies use of outdated ciphers offered by Java. The Java does not know of newer ciphers offered by the mail server.
    • A newer Java version 17 is used to connect to a mail server that is operated with older ciphers.
      • The Java denies use of outdated ciphers offered by the mail server. The mail server does not know of newer ciphers offered by Java.

...