It is indeed
mail.<protocol>.ssl.socketFactory.class
(see line 88, MailConnection#MAIL_SSL_FACTORY_CLASS -> uses reflection
to create an instance of the specified factory.
or
mail.<protocol>.ssl.socketFactory
(which requires adding a pre-configured and instantiated factory
instance into the properties of the mail session)
To be complete, I will add this way to the README as well.
Am Mittwoch, den 02.12.2020, 16:24 +0100 schrieb Romain Manni-Bucau:
> Isnt the property mail.<protocol>.ssl.socketFactory ?
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
>
> Le mer. 2 déc. 2020 à 16:09, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> > Okay. Thanks for the feedback - today, I learned a lot about the
> >
> > insides of Javamail :)
> >
> >
> >
> > I have updated my PR:
> >
> >
> >
> > - Updated README.txt to contain some documentation about setting a
> >
> > custom ssl socket factory
> >
> > - Dropped TLSv1 in the fallback protocols (if no custom set
> > properties
> >
> > are present)
> >
> >
> >
> > Thanks,
> >
> > Richard
> >
> >
> >
> >
> >
> > Am Mittwoch, den 02.12.2020, 15:29 +0100 schrieb Romain Manni-
> > Bucau:
> >
> > > Guess you can just create a readme in the geronimo-javamail root
> >
> > > project, will be sufficient as a first step.
> >
> > > Abou he default I wonder if dropping tlsv1 cant be good since it
> > will
> >
> > > be dropped soon?
> >
> > > Otherwise just adding the missing "o" in protocols i'm fine with
> > your
> >
> > > proposal.
> >
> > >
> >
> > > We need to refine if we do a javamail subsite or a generic spec
> >
> > > subsite sill :s.
> >
> > >
> >
> > > Romain Manni-Bucau
> >
> > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
> >
> > >
> >
> > >
> >
> > > Le mer. 2 déc. 2020 à 15:26, Zowalla, Richard <
> >
> > > richard.zowa...@hs-heilbronn.de> a écrit :
> >
> > > > I updated the diff (cf. v2) to (hopefully) address the concerns
> >
> > > > raised
> >
> > > > (if I understood them correctly).
> >
> > > >
> >
> > > > If you point me to a location where I can add a README /
> >
> > > > documentation,
> >
> > > > I would be happy to fill another JIRA with a related PR to
> > document
> >
> > > > the
> >
> > > > usage of the custom ssl socket factory.
> >
> > > >
> >
> > > > Am Mittwoch, den 02.12.2020, 13:58 +0000 schrieb Zowalla,
> > Richard:
> >
> > > > > Thanks for your thoughs - I think, I get the idea.
> >
> > > > >
> >
> > > > > Maybe:
> >
> > > > >
> >
> > > > > - Using "mail.smtp.ssl.protocls" to allow easier
> > configuration
> >
> > > > (as
> >
> > > > > proposed in the PR) for
> > MailConnection#getConnectedTLSSocket() -
> >
> > > > > would
> >
> > > > > address 1.
> >
> > > > >
> >
> > > > > - To address 3. and pre-claim: PR would enable all protocols;
> >
> > > > maybe
> >
> > > > > address this concern by adding a default fallback pointing to
> >
> > > > TLSv1,
> >
> > > > > TLSv1.1, TLSv1.2 and TLS v1.3 (if supported) if no custom
> >
> > > > > configuration
> >
> > > > > via "mail.smtp.ssl.protocls" is present?
> >
> > > > >
> >
> > > > > - Documentation is always appreciated ;)
> >
> > > > >
> >
> > > > > Wdyt?
> >
> > > > >
> >
> > > > > Am Mittwoch, den 02.12.2020, 14:41 +0100 schrieb Romain
> > Manni-
> >
> > > > Bucau:
> >
> > > > > > Yes but issue that we don't want to enable them all too.
> >
> > > > > > So to be concrete what about:
> >
> > > > > >
> >
> > > > > > 1. Enable a smoother configuration (to avoid a custom
> > class)
> >
> > > > > > 2. Document the custom class case better (at least in a
> > readme)
> >
> > > > > > 3. Change a bit default to inherit JVM ones
> >
> > > > > >
> >
> > > > > > Think we should make the 3 to consider this case treated
> > (does
> >
> > > > not
> >
> > > > > > mean it must be in the same PR but more before next
> > release).
> >
> > > > > > Wdyt?
> >
> > > > > >
> >
> > > > > > Romain Manni-Bucau
> >
> > > > > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
> >
> > > > > >
> >
> > > > > >
> >
> > > > > > Le mer. 2 déc. 2020 à 13:20, Zowalla, Richard <
> >
> > > > > > richard.zowa...@hs-heilbronn.de> a écrit :
> >
> > > > > > > Ah sorry - I misunderstood your comment.
> >
> > > > > > >
> >
> > > > > > > A custom socket factory would indeed fix the problem, but
> > it
> >
> > > > is
> >
> > > > > > > rather undocumented.
> >
> > > > > > >
> >
> > > > > > > Nevertheless I think, that the default fallback shouldn't
> > be
> >
> > > > > > > hardcoded or at least support some more protocols...
> >
> > > > > > >
> >
> > > > > > > Best and thanks for the idea,
> >
> > > > > > > Richard
> >
> > > > > > >
> >
> > > > > > > Am Mittwoch, den 02.12.2020, 12:16 +0000 schrieb Zowalla,
> >
> > > > > > > Richard:
> >
> > > > > > > > Honestly I didn't. I discovered the hard-coded
> >
> > > > > > > > String[]("TLSv1")
> >
> > > > > > > > in
> >
> > > > > > > > MailConnection#getConnectedTLSSocket(), which is (imho)
> > a
> >
> > > > bit
> >
> > > > > > > > odd.
> >
> > > > > > > >
> >
> > > > > > > > Imho, users should either be allowed to specify the
> > enabled
> >
> > > > > > > > (and
> >
> > > > > > > > supported) protocols or to use the default ones
> > provided by
> >
> > > > the
> >
> > > > > > > > jdk
> >
> > > > > > > > classes :)
> >
> > > > > > > >
> >
> > > > > > > > This is already done for
> >
> > > > MailConnection#getConnectedSSLSocket
> >
> > > > > > > > but
> >
> > > > > > > > not
> >
> > > > > > > > for the TLS handling.
> >
> > > > > > > >
> >
> > > > > > > >
> >
> > > > > > > > Am Mittwoch, den 02.12.2020, 13:09 +0100 schrieb Romain
> >
> > > > Manni-
> >
> > > > > > > > Bucau:
> >
> > > > > > > > > Hi Richard,
> >
> > > > > > > > >
> >
> > > > > > > > > Did you try a custom socket factory? In such a case
> > you
> >
> > > > fully
> >
> > > > > > > > > control
> >
> > > > > > > > > it.
> >
> > > > > > > > >
> >
> > > > > > > > > Romain Manni-Bucau
> >
> > > > > > > > > @rmannibucau | Blog | Old Blog | Github | LinkedIn |
> >
> > > > Book
> >
> > > > > > > > >
> >
> > > > > > > > >
> >
> > > > > > > > > Le mer. 2 déc. 2020 à 13:01, Zowalla, Richard <
> >
> > > > > > > > > richard.zowa...@hs-heilbronn.de
> >
> > > > > > > > > > a écrit :
> >
> > > > > > > > > > Hi,
> >
> > > > > > > > > >
> >
> > > > > > > > > > I did some debugging and found, that TLSv1 is hard-
> >
> > > > coded in
> >
> > > > > > > > > > MailConnection.java in v1.0.0 of Geronimo Java
> > Mail.
> >
> > > > > > > > > >
> >
> > > > > > > > > > I filled a JIRA [1], which contains a patch
> > proposal.
> >
> > > > > > > > > >
> >
> > > > > > > > > > Happy to receive some feedback.
> >
> > > > > > > > > >
> >
> > > > > > > > > > Thanks in advance,
> >
> > > > > > > > > > Richard
> >
> > > > > > > > > >
> >
> > > > > > > > > > [1]
> >
> > > > > > > > > > https://issues.apache.org/jira/browse/GERONIMO-6792
> >
> > > > > > > > > >
> >
> > > > > > > > > >
> >
> > > > > > >
> >
> > > > > > > --
> >
> > > > > > >
> >
> > > > > > > Richard Zowalla, M.Sc.
> >
> > > > > > > Research Associate, PhD Student | Medical Informatics
> >
> > > > > > >
> >
> > > > > > > Hochschule Heilbronn – University of Applied Sciences
> >
> > > > > > > Max-Planck-Str. 39
> >
> > > > > > > D-74081 Heilbronn
> >
> > > > > > > phone: +49 7131 504 6791
> >
> > > > > > > mail: richard.zowa...@hs-heilbronn.de
> >
> > > > > > > web: https://www.mi.hs-heilbronn.de/
> >
--
Richard Zowalla, M.Sc.Research Associate, PhD Student | Medical Informatics
Hochschule Heilbronn – University of Applied SciencesMax-Planck-Str. 39 D-74081
Heilbronn phone: +49 7131 504 6791mail: richard.zowalla@hs-heilbronn.deweb:
https://www.mi.hs-heilbronn.de/
smime.p7s
Description: S/MIME cryptographic signature
