Gmail SMTP timeout after sending data block, Connection timed out

trogvar · October 19, 2021, 2:24pm

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 H=gmail-smtp-in.l.google.com [108.177.127.26] TLS error on connection (send): The TLS connection was non-properly terminated.
2021-10-19 16:46:25 1mco59-0008tT-BX H=gmail-smtp-in.l.google.com [108.177.127.26]: 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
10.10.10.10:my.mail.domain.com

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

Thanks!

cmstew · October 19, 2021, 4:21pm

Hey trogvar,

It’s supposed to be an ip:my.mail.domain.com pair.

Was the IP address a local IP?

trogvar · October 19, 2021, 4:35pm

It’s supposed to be an ip:my.mail.domain.com pair.

Yes, I know that.

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

cmstew · October 19, 2021, 4:46pm

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:

github.com

hestiacp/hestiacp/blob/main/install/deb/exim/exim4.conf.template#L12

    
      
          #                                                                    #
          #          Exim configuration file for Hestia Control Panel          #
          #                                                                    #
          ######################################################################
          
          
#SPAMASSASSIN = yes
          #SPAM_SCORE = 50
          #CLAMD = yes
          
          
smtp_banner = $smtp_active_hostname
          smtp_active_hostname = ${if exists {/etc/exim4/mailhelo.conf}{${lookup{$interface_address}lsearch{/etc/exim4/mailhelo.conf}{$value}{$primary_hostname}}}{$primary_hostname}}
          add_environment = <; PATH=/bin:/usr/bin
          keep_environment =
          disable_ipv6 = true
          
          
domainlist local_domains = dsearch;/etc/exim4/domains/
          domainlist relay_to_domains = dsearch;/etc/exim4/domains/
          hostlist relay_from_hosts = 127.0.0.1
          hostlist whitelist = net-iplsearch;/etc/exim4/white-blocks.conf
          hostlist spammers = net-iplsearch;/etc/exim4/spam-blocks.conf
          no_local_from_check

trogvar · October 19, 2021, 4:49pm

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

cmstew · October 19, 2021, 4:56pm

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.

trogvar · October 19, 2021, 4:58pm

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

cmstew · October 19, 2021, 5:00pm

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 ip:mail.domain.com pair?

trogvar · October 19, 2021, 5:23pm

Yes, hostname is the same as mail server.

Deepak · October 19, 2021, 7:36pm

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

Deepak · October 19, 2021, 7:40pm

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:

123.456.123.567:rDNS.com

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.

trogvar · October 19, 2021, 7:49pm

Thanks for reply.
10.10.10.10 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.

Deepak · October 19, 2021, 7:55pm

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.

pluto · October 20, 2021, 6:30am

I had a problem with one server sending to gmail when the ip:domain.com didn’t match my actual server hostname.
Also maybe check the PTR record for that IP address.
dig x domain.com
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.]

trogvar · October 20, 2021, 6:46am

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

eris · October 20, 2021, 6:52am

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

eris · October 20, 2021, 7:01am

Created a new issue for improving the lookup for helo…

trogvar · October 20, 2021, 7:08am

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

eris · October 20, 2021, 7:25am

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

Deepak · October 20, 2021, 7:36am

You need the following:

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