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
>> >
>>
>
