We'd love to hear about it! Click here to go to the product suggestion community
We have some serious outgoing Email issue since last night. Emails are filling up the SMTP spool, but are eventually delivered at some point in time.
Setup: internal Exchange who sends Email to UTM SMTP Proxy. The Proxy is utilizing our ISP's Smarthost. The configuration wasn't changed and worked flawless for months and years.
Since 2100 last night, new Emails are not being send out:
2019:07:11-13:00:30 mail exim-out: 2019-07-11 13:00:30 1hlWLY-0008Ft-4A == email@example.com R=smarthost_route T=smarthost_smtp defer (-46): SMTP error from remote
mail server after end of data: host wp12950791.mailout.server-he.de [18.104.22.168]: 421 wp460.webpack.hosteurope.de SMTP incoming data timeout - closing connection.
From that point onwards, the Email is sitting in the spool:
2019:07:11-13:00:48 mail exim-out: 2019-07-11 13:00:48 1hlWLY-0008Ft-4A ==
firstname.lastname@example.org R=smarthost_route T=smarthost_smtp defer (-53): retry time not reached
for any host
In regards to the retry time message, I followed the guidance in some other threads and flushed the DNS cache + restarted the UTM. But the problem persists.What can be the problem? I currently have no clue how to fix it, but have a lot of users calling me up. :-/
Searched the logs some more, and found some other issue. What exactly does that mean?
2019:07:10-21:27:43 mail exim-out: 2019-07-10 21:27:43 1hl77M-0007ia-Gg SSL_write: (from [192.168.2.14]:999) syscall: Broken pipe2019:07:10-21:27:43 mail exim-out: 2019-07-10 21:27:43 1hl77M-0007ia-Gg SSL_write error 52019:07:10-21:27:43 mail exim-out: 2019-07-10 21:27:43 1hl77M-0007ia-Gg wp12950791.mailout.server-he.de [22.214.171.124]: Broken pipe2019:07:10-21:27:43 mail exim-out: 2019-07-10 21:27:43 1hl77M-0007ia-Gg == email@example.com R=smarthost_route T=smarthost_smtp defer (32): Broken pipe: wp12950791.mailout.server-he.de [126.96.36.199]
In reply to reag:
After researching the broken pipe error in the UTM forum, I came along a thread that recommended to "skip TLS negotiation hosts/nets". I have added both the internal Exchange and the ISP's smarthost, and the Emails went out within seconds!
Shall it be like that? What exactly did I do there? I have had a quick look at Exchange, certificates are valid until 2020. Is that something the ISP needs to fix?
This morning, I have created Let's Encrypt certificates on the UTM for the external addresses. I have reenabled the TLS negotiation, and added the new certificate for our main line as the TLS certificate. So far, it is working flawless again.
I can only assume that our ISP maybe hardened the configuration for the smarthost, requiring certificates by a trusted CA. Until today, we used the standard, self-signed webadmin certificate, which no longer seems to work (cert is still valid).