Gmail SMTP timeout after sending data block, Connection timed out

There was some strange behavior of exim4 on my fresh HestiCP install (Debian 11).
Severeal servers ignored my mail and I received:

1mco59-0008tT-BX [] TLS error on connection (send): The TLS connection was non-properly terminated.
2021-10-19 16:46:25 1mco59-0008tT-BX []: SMTP timeout after sending data block (476555 bytes written): Connection timed out

or even:

: 550 #5.1.0 Rejected by bounce verification.

I found that my /etc/exim/mailhelo.conf contains data like this: ip:domain

I changed it to:
where is hostname and name that in PTR and everything worked.


Hey trogvar,

It’s supposed to be an pair.

Was the IP address a local IP?

It’s supposed to be an pair.

Yes, I know that.

It was external host ip. But Google and some servers didn’t accept mail with this HELO settings.

okay, well your fix only appears to be working because it causes the check in the exim config to fail. And when it fails, it defaults to the $primary_hostname exim variable which is the same as what you would get if you checked your /etc/hostname file.

Here is a link to the relevant line in the exim config:

Thanks, I’ve seen this in config file.

Here is exim config test:

Exim version 4.94.2 #2 built 13-Jul-2021 16:04:57
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event I18N OCSP PIPE_CONNECT PRDR PROXY SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated

Hmm, that doesn’t tell me much. Your solution works. So I’m glad you’re able to keep sending, but there’s a better solution to this problem somewhere. I’ll look into it and get back to you later. :slight_smile:

Thanks :slight_smile: I’ll try to revert changes in mailhelo.conf and find the other reason of my errors.
Seems it really should be ip:hostname. :frowning:

I wouldn’t revert the changes until you have another fix. Like I said, your fix is working, but only because it breaks the exim check and falls back to the default hostname. Which isn’t necessarily a bad thing. As long as you only send mail from 1 ip address, it’s not really a big deal.

Does your hostname in /etc/hostname match what you had for the second part of the pair?

Yes, hostname is the same as mail server.

For the purpose of negotiation with MTA, the hostname is not relevant. You could insert a different, where the hostname can be After the protocol is exchanged and negotiation is complete, the information is inserted in the header of an email. At this time, the is checked before accepting the dta and filtered through ACLs of exim4.conf.

You cannot have a LAN IP in there for a negotiation of this service with a remote server outside of the LAN. Here, it will simply bind the service to relay or connect to LAN ips.

Consequently, you get a time-out.

Insert the IP of the server and then use the domain that you have a rDNS for. So it will look like:

Then, Google will begin an exchange. Mind you, you also need to setup DMARC/SPF/DKIM for a successful transmission with most remote MTA as they do check these things.

Now if you use Cloudflare, let me know. Then things should be explained a bit different.

Thanks for reply. was an example for the post, I have a real external IP there.
And it works at the moment, I will monitor it tomorrow under the load.
And yes, DMARC/SPF/DKIM are exist and working.

I see. So you did not have a LAN IP in there and substituted for privacy. Then, the problem is somewhere else because this HELO setting is fine. I use it like this and my server have no problems with Google transmissions.

Only once I had a problem of a similar nature. My shell scripts to do mass change of IPs in Cloudflare through their API masked the port. Then, I had a similar problem. But it does not look like you use their service. So trace it somewhere else.

1 Like

I had a problem with one server sending to gmail when the didn’t match my actual server hostname.
Also maybe check the PTR record for that IP address.
dig x
And also maybe check if you’re behind a proxy like cloudflare which may be changing your apparent public IP.
[I’ve started turning off cloudflare for any mail domains. It seems to break things far more than it should.]

1 Like

IP is correct as PTR record also correct and I have real external IP.

we are considering changing the Helo look up method the method that we have used can be improved a lot.

Created a new issue for improving the lookup for helo…

Yes, I’ve reverted back to ip:domain and it stopped sending mail to GMail again.

It should be ip:rnds value it should be then working again

You need the following:
where ==
At the time of negotiation, it will invoke the domain “” for the exchange of data. Thus, before it has to resolve the rDNS. Following this, your rDNS should be setup
I believe that this could be your problem. If you have, it will not transmit the data, give a connection time out because the MTA waits for the to respond.