It affects various providers, some of which I am pretty sure that they are not using Gmail in the background.
I understand that error is usually something to do with the receiving party, but I doubt that 10+ different email providers have an issue all of a sudden.
I have all green checkmarks in my MIAB dashboard. And sending within my own MIAB works.
So, as a test I thought, how about sending an email to another known MIAB user? I do not know any, so would someone be willing to share their email (via private message), so I can send a test message to them and see if the error persists?
Check your server admin → System / Status Checks. There should be zero errors or warnings.
Try sending FROM gmail/outlook/whatever TO your server, and wait for any bounce/error replies. Those services can be picky about who can send to them, but they’re usually happen to send to anyone.
If you can get an email from (say) gmail, then see if you can send a reply to the sender.
I’ve found the following webites useful, though they do assume a level of IT knowledge:
I have all green check-marks, no errors or warnings.
I can receive email just fine on various domains and accounts on this MIAB.
MXToolbox reports blackllsted on Uceprotectl3 which my MIAB was on that for at least 24 months now.
DKIMValidator does not receive my email.
Internet.nl points at some TLS and ciphers that should be phased out. Further a DANE scheme is missing. Finally, the one that stands out to me a bit (not sure if it is the main issue though) is that there is no route authorisation (RPKI). All my secondary NS have it I will look into that further, although the MIAB dashboard makes no reference to it.
Out of curiosity, see if your box can connect to the gmail servers. Try: nc 142.251.163.27 25 nc 2607:f8b0:4004:c1b::1a 25
For each, you should get a reply like: 220 mx.google.com ESMTP 6a1803df08f44-6d88de63cd3si32667756d6.378 - gsmtp
(then clobber the nc with ^C).
Those IP addresses are for gmail. If you can get an nc connection and a reply, then your box can see the gmail server. If not, there’s your problem …
PS. Unless you’ve completely disabled either IPv6 or IPv4 (!), I think you’ll need to be able to get a connection on both, because MIAB could use either when trying to send.
I have both IPv4 and v6 enabled. That is the thing, this box ran fine for some two years, without me modifying anything from the stock script and all of a sudden 10+ providers can not receive email without any indication? It is strange.
Time to get your hands dirty … so to speak. Have a good look through the log files and work out what’s going wrong.
The mail mail log is /var/log/mail.log
You can make the system generate more detail by editing /etc/postfix/master.cf and adding -v to the line (near the top) like: smtp inet n - y - - smtpd
becomes smtp inet n - y - - smtpd -v
then run the command postfix reload to enable the updated config.
Adding more v’s (like -vvv) provides even more log detail.
The logs will show you (up to quite a lot of detail) exactly the connections made, replies received, etc. You’ll learn more about emal than you wanted to know, but that’s part of running your own server
@andrew
Mg344 send me a message. All seems fine just a delay of 6 hours.
It seems that he is sending via relay @Mg344
Type in terminal when you send a message and see the reply. cat /var/log/mail.log | grep "postfix/smtp" | grep -P 'status='
Login there maybe there is a setup for delayed sending? Or change your relay provider. MailJet, MailGun Sendgrid all offer free service.
Otherwise just send via your own box if Outbound Port 25 is not blocked
By the way I see from your SPF that you have an account with AnyMXRelay
Maybe @alento could be of some help here as he maintans that relay?
In /etc/postfix/main.cf I found smtp_tls_security_level=encrypt was commented out. I removed the # on that line.
Following that, the log showed
warning: /etc/postfix/main.cf, line 38: overriding earlier entry: smtp_tls_security_level=dane
So i commented that option out.
Emails are now being received instantly again. However, if this was the right thing to do with regards to MIAB configuration, I do not know. I guess, I have to be vigilant when doing a future update.