Re: Could not convert socket to TLS

--0000000000002e6e60063abc50cd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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: [email protected]
URL: www.International-presence.com




On Thu, 24 Jul 2025 at 16:15, Benoit TELLIER <[email protected]=
>
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/c=
onfigure/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: [email protected]
> Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)
>
>
> On Jul 24, 2025 3:29 PM, from Rupesh Singh <[email protected]>Hi, can
> disable ssl and test to ensure cert is the issue.
> Thanks,
> Rupesh
>
> On Wed, Jul 23, 2025 at 12:14=E2=80=AFPM Matt Pryor <
> [email protected]> 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=3D"relay" enabledJmx=3D"true">
> >    <mailet match=3D"ALL" class=3D"RemoteDelivery">
> >        ....
> >        <startTLS>true</startTLS>
> >    </mailet>
> > </processor>
> >
> > I enabled -Djavax.net.debug=3Dssl:handshake:verbose, -Dmail.debug=3Dtru=
e 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 matc=
h
> > 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=3D* 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: [email protected]
> > URL: International-presence.com
> >
>

--0000000000002e6e60063abc50cd--