Greetings Matt from Germany, from Matt from England! Many thanks for the detailed response.
Working with openssl and online tools I found that in one instance the cert CN did not match the mail domain name, in another the root CA wasn't trusted. This happens with a small percentage of the customer's emails. Really I would have liked to get James / Javamail to fall back to non-TLS in such situations but then I appreciate that's also not very secure, and anyway the setting seems to get ignored or doesn't do as I expected, so the customer will just have to live with some emails not getting delivered. Kind regards Matt Pryor Research and Development Manager The International Presence Group of Companies EMAIL: pr...@presencebpm.com URL: www.International-presence.com On Sat, 16 Aug 2025 at 21:18, cryptearth <cryptea...@cryptearth.de.invalid> wrote: > 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 > >
