your mail server do not offer TLS protocol, thus e-mails from your clients are not delivered to you. This is a case when sender SMTP is configured to require TLS security on connection to remote SMTP. Such a configuration is very common nowadays.
The following error message is received by the sender:
“This is the mail system at xxxxxxxxx.
I’m sorry to have to inform you that your message could not be delivered to one or more recipients. It’s attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can delete your own text from the attached returned message.
The mail system
<support@mikrotik.com>: TLS is required, but was not offered by host
mailgw2.mt.lv[159.148.172.134]”
Shouldn’t your SMTP service provider solve this, since he imposes an optional feature as mandatory?
It is not common not to send mail if TLS is not offered by the receiver. That restriction should be imposed only by the mail recipient’s server, but only on servers not intended to be general reachable.
BTW, what is the added security to apply that restriction on outgoing messages anyway? Governmental sniffing protection? Because regular hacking doesn’t occur in ISPs backbones…
TLS protocol is an Internet standard since over 15 years !
Some mail server admins are so lazy, that even after 15 years they don’t update protocols supported by mail server. I hope that MikroTik mail server admin will fix this oversight promptly.
docmarius: Do you login to your eBank account using HTTP instead of HTTPS, because hacking doesn’t occur in ISPs backbones ? Good luck!
It may be standard, but it isn’t requirement for SMTP. There’s no way you can force all mail server operators to enable it. If you require TLS for outgoing connections, you won’t be able to reach a lot of destinations. On top of that, TLS is one thing and trusted certificates another and be sure that many small servers do not have them. Such “security” is then useful only against common user with packet sniffer. If just enabling TLS was hard, this is completely different level.
I agree with you, that vast majority of mail servers with TLS support use self signed certificates. However, even TLS with self signed certificate is far more secure then plain text.
I know, how hard is to change lazy habits of mail server administrators but increasing users awareness can change it.
To set up TLS is a minimal additional effort compared to setting up a complete mail server with access rules dealing with regular access, complete auth and policy rules, spam filtering, rbl validation and other goodies. So I don’t see the “lazy” part here.
It’s very easy to drop such classifications if it involves others to do something, just because they do things differently.
They choose an agreed standard way, your side chooses to bend the rules for their own liking and minimal effort.
And as I said, sniffing is the least important issue on mail messages. It is spoofing, DNS hijacking, fake auth (and here the false security impression of TLS often “helps” alot) and other techniques, which do not rely on intercepting a mail messages en route.
So if you think that braking the established RFC conform SMTP standard is the way to go, you have to live with the consequences of not being able to send mail to some destination. It was your personal choice.
And I don’t think that by calling the people “lazy” they will just jump to solve the issue, being asked so “nicely” to fix YOUR problem.
? Good luck! 