Hey Matt,
I dug a bit deeper and the fallback you'd like to seems not gonna happen
without quite a lot of work from the devs.
According to RFC 3207 StartTLS in SMTP can have 3 replies:
220 Ready to start TLS
This is the regular reply when the server accepted the StartTLS request
and is ready to initiate the TLS handshake.
501 Syntax error (no parameters allowed)
By RFC 3207 the StartTLS command is not followed by any additional
parameters. So this might get thrown when the server gets anything after
StartTLS and does not just throw it away.
454 TLS not available due to temporary reason
Well - the message says it: Not available.
The "fallback" is likely only for a 501 or a 454 when the server denies
TLS at all. The RFC says: "It's up to the client how to proceed."
But in your case your James gets a 220 and starts the handshake - but
fails that. According to TLS specs this is a TLS ALERT and both the
server and client MUST abort the connection if an ALERT is raised.
So for trust path failures you're already past the 220 accept from the
server and inside the tls handshake. Termination is the correct failure
resolution at this point.
How could it possible to implement a fallback: Well, first of the server
needs to support it. A server following the TLS spec will terminate the
TLS hanshake anyway. But if it would not the handshake could be aborted
without terminating the underlying TCP connection and switching back to
plain text. But I doubt that's what you're looking for.
So, unfortunately, to repeat myself: Same as with Ilja for your issue
the cause is the remote server. Nothin you can do on your side.
However - one might could think about trying to implement something like
"try-ahead": Probing the remote server if StartTLS is offered, try it
and when it fails don't use StartTLS on the actual connection at all. As
for simple MTA-to-MTA transfer this should be fine as no user
credentials are exchanged but just the message itself. And if a mail
conains sensible data it should be client encrypted with s/mime or pgp
anyway.
So long.
Matt
Am 20.08.25 um 15:58 schrieb Matt Pryor:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org