Well, i am usingg the mx register to find who manages the server, then i
look for a web page and then i send an email to the contact address.
I've never had received an aswer so they dont care or i notify then
wrong address, but on any case them problem dont get corrected.
But that surprise me, why i as a mail admin going to config tls support
but ignore the basic configs i have set, so tht's why my question here.
We set our own mail server for 2 reasons, one is to have full control of
our company addresses and because some apps who we sell needs to send
mails and right know every user has to configure its own mail account
(yahoo, gmail, it's own server, etc). So we decide to avoid that
conflict offering native sending alternative and we enable it in a group
of users but we did not expect those TLS errors, and as you said is our
job to be sure emails are arriving to its recipients.
To get this around i am thinking in configure 2 remote delivery mailets,
one for those apps and one for our company address, the routing strategy
could consist on who is sending, if it is a kind of noreply account,
then use remote delivery 1 (with TLS disabled), if it is a valid user,
then use remote delivery 2.
Another third solution could consist in show the status of the emails a
user of these apps sent, and when they see an error notify the recipient
so maybe this recipient can talk to his/her IT guy and he/she resolves
the problem, because what we observed is that all emails servers with
TLS problems are not big tech companies, all of them seem to use custom
services.
Thanks for your answer.
En 23/08/2025 06:24 p.m., cryptearth escribió:
Hey Ivan,
welcome to Apache James.
There's actually a very recent topic about that very issue:
https://www.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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
