Hello everybody I am late to jump on that thread, sorry. (I enjoyed relaxng vacations that I much much needed!)
Disclaimer: At LINAGORA we do not use James for out deliveries, we tend to rely on Postfix for it. This served us well (we have big infra and using James solely as a MDA is ok). But this means we do not have much expertise running James as a Mail Relay Agent. I read the thread in diagonal and I am sadned the conclusions are: - run unsecure options with clear mail traffic or - do unlimited bureaucracy while suffering delivery failures visible to the user with no certainty of success I believe there's a 3rd way: being able to relax (more than today) the certificate validation. I drafted quickly a proposal of customizing the SSL context and its trust manager CF https://github.com/apache/james-project/pull/2788 I am happy if people can give this a try and provide feedback. Cheers all. -- 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 Aug 24, 2025 2:24 AM, from Cryptearth <cryptea...@cryptearth.de.INVALID>Hey Ivan, welcome to Apache James. There's actually a very recent topic about that very issue: mail-archive.com/server-user@james.apache.org/msg17186.html In the end it comes down to: James lacks the ability to perform a non-TLS retry when outgoing StartTLS is enabled and it fails due to some TLS ALERT (like the issues you mentioned). Recommendations? If you provide others with your service it's your job to make sure your users mails get to thier targets. Using James the option is to disable outgoing StartTLS and just don't bother with it. A more sophisticated approach would be to figure out hostmaster/postmaster contact info and try to reach out for the postmaster in charge to inform them about the issue. But depending on how many you have to deal with this can take up hours. If you're like me and just use your domain and server for your very self - well, then just ditch them. If they don't get thier shit in order why bother to deal with them? Unfortunately this is kinda of those "it depends" sitations: Following good code it's your responsibility to at least try to reach out to those in charge at least try to inform them. But if there's no other way (like the hostmaster/postmaster contact info lead to nowhere or just back to where you came from) and even try to contact them by classic physical letter fails then there's not much you can do. As an example: As I have a .de domain it's registered by the german authority DeNIC. My actual registrar is InterNetworX. I've set them as my hostmaster. So when you do a whois on DeNIC and click on "technical contact" you get hostmas...@inwx.de. At inwx there's my gmail.com mail address registered. So if anyone has issues with reaching me via e-mail they can contact my registrar and request them to contact me. You have a mexican domain. Your registrar seems to be HOSPEDANDO.MX. And although I wasn't able to find a hostmaster contact I figured they use cloudflare. So in the end if I have trouble to contact you via e-mail because your mail server acts up I could try to contact cloduflare for the hospedando hostmaster or the mexican authority nic.mx. And although none of them would hand me out any information about you as I'm not a three-letter "men's club" based in the usa I can request them to try to contact you via other means and inform you: "Hey, we got information that you messed up your mail server and this guy from germany can't send you mails. Fix that please.". Hence I recommend have some global reachable contact like a gmail or similar with your registrar. That's how it's supposed to work. How much effort you put into all of this - well, that's up to you. So long ... Matt Am 23.08.25 um 18:43 schrieb Ivan Perales: > I am new to manage a mail server, but since i am a java programmer i > wanted a software that were easly to adapt to my needs, so when i > found apache james it fits like a glove. > > So in my journey to set it in prod mode i found a lot of problems > which i could resolve, for example (understad that i was new) SFP, > DKIM, setting correct ehlo name and similars. But the ones i am no > sure if have to resolve on my side are those ones involved with TLS > communication. My servers logs different fails like: > > * unable to find valid certification path to requested target > > * Can't verify identity of server: <domain server here> > > * Certificate expired > > Checking those certs on the target mail server i found that they are > to old, or self signed, that of course means a configuration problem, > but they're been running for months even years, if they wouldn't had > receiving mails they would had correct it, right? so in order for them > to keep that bad config means other server by passes those native cert > restrictions and send emails anyway. > > So my question is.. do i need to do that too? this would mean to > avoid the nature of certs, so if this has to be this way, why concern > about implementing TLS? just for encryption? I set the remote delivery > config of verifyServerIdentity to false to bypass one kind of error, > but what about the others? What do you recommend me to do? > > > Thanks for your time. > --------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
