Hi Matt,
first up: If you get some issue of some trustpath can't be established
it's usually the remote. But it could also on your end missing some root
ca certs.
A test I like to use for my own server is this:
https://www.checktls.com/TestReceiver
The default settings give you a good first clue what's the issue here.
If this test also fails to resolve the trustpath then it's clearly an
issue on the remote side using either self-signed certs (or signed by a
CA unknown to you) or expired certs.
You can also play around with the additional options. The ones I like to
use are:
- check DANE
- check cert sigs
- ignore no connections
- ipv4
- ipv6
- check dnssec
- no dns cache
- check crl
- check ocsp
Next: SMTP as by RFC usually defines a fallback to non-tls when starttls
fails - but it's up to the clients decision. I'm not sure if James uses
standard JavaMail lib for outbound connections - but given it's in the
libs folder (and a very old version of 1.6.2 from 2018) I guess so. It's
docs states:
mail.smtp.starttls.enable - If true, enables the use of the STARTTLS
command (if supported by the server) to switch the connection to a
TLS-protected connection before issuing any login commands. If the
server does not support STARTTLS, the connection continues without the
use of TLS; see the mail.smtp.starttls.required property to fail if
STARTTLS isn't supported. Note that an appropriate trust store must
configured so that the client will trust the server's certificate.
Defaults to false.
mail.smtp.starttls.required - If true, requires the use of the STARTTLS
command. If the server doesn't support the STARTTLS command, or the
command fails, the connect method will fail. Defaults to false.
Question comes up: The required flag states that when set and StartTLS
fails the connection will fail. But does that mean that without required
flag set and only the enable flag that it will tolerate a fail of
StartTLS? And what kind of failure?
Your try to set the required flag via the config doesn't wok because
that's not how the James xml config work in general. You could, however,
try to add the flag to your start script:
-Dmail.smtp.starttls.required=false
But this will only work if it's not overwritten somewhere in the code
that sets up starttls.
Also: I guess "command failing" only means that the server sends a
proper smtp reply to the StartTLS command other than 220. The issue we
get is way deeper in the TLS layer and not at the SMTP layer. And given
by the docs for the crypto stuff in java (sorry, there're a few combine
- won't list them here) this is an SSL ALERT to which the connection has
to be terminated. So even IF overwriting the required flag would work it
would be a violation of how ssl works and hence would likely be seen as
a vulnerability of javas ssl implementation.
TL;DR: Same as with Ilja: The error seems to be on the remote end and
there's little to nothing you can do about on your end. All you can do
is to check if external tools result in the same issue to verify if it's
on your system or the remote.
If external tools as linked can establish a working tls connection it
could be an issue with your java setup. On Windows Java comes with its
own root-ca store. On linux it uses the systems one at
/var/lib/ca-certificates.
So check the affected domain with checktls.com what kind of certificate
they use. If it's a selfsigned: Try to contact them via other means and
ask: "Why?" and "Have you heard of Let's Encrypt?". If they use a CA
unknown to you: Could be the mail server you try to connect is part of
some internal or closed system.
example: In germany the energy industry uses a closed system for S/MIME
secured mail exchange. The certificates are signed by a special
non-public government CA specific for this network only. Although these
mail servers are connected to the public internet they are not announced
anywhere but only in a closed register so it's kind of a closed net but
only in the terms of: There's no public list like DNS. Same is true for
the project "E-Mail made in Germany" - a network where a few big germany
providers have established a "secure" closed network in which they only
accept mails from eachother. The idea is that a client of Telekom can be
sure that a mail from 1&1 really came from there. But this is flawed as
it only gives an idea about "yea, a mail within this network was sent by
one of the servers of one of them few" but not "was this a legit mail or
just spam of a hacked account".
For us to help you we need some example domains affected by this issue -
as far as you can share them, of course.
Have a nice weekend everybody.
Greetings from Germany
Matt
Am 04.08.25 um 11:54 schrieb Matt Pryor:
Hi all, a follow up on this.
After enabling debug on the remote delivery mailet I can see that a number
of messages are failing for various different reasons but the main reason
I'm seeing is "unable to find valid certification path to requested target".
2025-08-01 15:30:42.575 [DEBUG] o.a.j.t.m.r.d.MailDelivrer - Could not
convert socket to TLS
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
From my experience this means that the remote server's SSL certificate is
self-signed, or signed by an untrusted SSL authority.
What is the normal way of handling this for large volume mail servers, as
it must happen a lot.
My idea was to add the following to the RemoteDelivery Mailet config:
<debug>true</debug>
<startTLS>true</startTLS> <!-- added by MP 2025-07-17-->
<mail.smtp.starttls.required>false</mail.smtp.starttls.required>
I hoped this would cause it to fall back to plain text if TLS could not be
negotiated for the above type of reason
However it seems to be getting ignored or doesn't work as I expected, as
it's still failing messages with TLS errors after n attempts.
Any further ideas please?
Kind regards
Matt Pryor
Research and Development Manager
The International Presence Group of Companies
EMAIL: pr...@presencebpm.com
URL: www.International-presence.com
On Fri, 25 Jul 2025 at 08:58, Matt Pryor <pr...@international-presence.com>
wrote:
Hi both, thanks for the suggestions.
Disabling StartTLS isn't an option as it's a production system.
I've asked the customer to correct their SSL certificate to see if it
fixes the issue for the time being.
If I still have problems I'll check out the verifyServerIdentity parameter.
Kind regards
Matt Pryor
Research and Development Manager
The International Presence Group of Companies
EMAIL: pr...@presencebpm.com
URL: www.International-presence.com
On Thu, 24 Jul 2025 at 16:15, Benoit TELLIER <btell...@linagora.com.invalid>
wrote:
Have you tried setting the verifyServerIdentity
property to false in remote delivery to false?
CF
https://james.staged.apache.org/james-project/3.9.0/servers/distributed/configure/mailets.html#_remotedelivery
verifyServerIdentityAlso
if you use self signed certificates you may consider unsing authoritative
ones for RemoteDelivery.--
Best regards,
Benoit TELLIER
General manager of Linagora VIETNAM.
Product owner for Team-Mail product.
Chairman of the Apache James project.
Mail: btell...@linagora.com
Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)
On Jul 24, 2025 3:29 PM, from Rupesh Singh <thaku...@gmail.com>Hi, can
disable ssl and test to ensure cert is the issue.
Thanks,
Rupesh
On Wed, Jul 23, 2025 at 12:14 PM Matt Pryor <
pr...@international-presence.com> wrote:
Hi all,
Running the latest code, Apache James 3.8.2 Server JPA Guice.
I'm seeing this error below when attempting to deliver to some
recipients'
mail servers:
2025-07-22 12:17:49.917 [DEBUG] o.a.j.t.m.r.d.MailDelivrer - Exception
delivering message
(Mail1753186668620-a77a76bb-d3f4-4170-9f5e-8ca8159a2276-to-zzzzzzz.com)
-
Could
not convert socket to TLS
2025-07-22 12:17:49.918 [INFO ] o.a.j.t.m.r.d.MailDelivrer - Could not
convert socket to TLS
My mailetcontainer.xml contains the following, it seems to work on most
occasions but (sod's law) not when the customer is testing it.
<processor state="relay" enabledJmx="true">
<mailet match="ALL" class="RemoteDelivery">
....
<startTLS>true</startTLS>
</mailet>
</processor>
I enabled -Djavax.net.debug=ssl:handshake:verbose, -Dmail.debug=true and
after inspecting stderr I believe what's causing it is not trusting the
remote server's SSL certificate which causes Javamail to abandon the
connection.
Testing with openssl, it seems that the SSL certificate CN doesn't match
the server hostname.
This must be a common problem in the wild.
Does anyone have any workarounds? I've tried setting
-Dmail.smtp.ssl.trust=* but it doesn't seem to make any difference.
Many thanks in advance.
Kind regards
Matt Pryor
Research and Development Manager
The International Presence Group of Companies
EMAIL: pr...@presencebpm.com
URL: International-presence.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
