It’s exactly as you describe:
ip:mail.mydomain.com
where ip - real ip for my mail domain.
when i check MX with this domain i receive mail.mydomain.com
when i check ip with nslookup - it gives mailmydomain.com, so PTR work for this pair
when i check nslookup mail.mydomain.com it gives correct ip.
And funny moment - I can’t send e-mail to exact gmail accounts, but to some of them it work like a charm. Send in seconds and people receive it. I’am out of ideas.
Heyyyyy, wait a moment, did you say that one or more email (“but to some of them”) could be transmitted to a Gmail account? In that case, your setup of MTA is correct. Then, the problem may not be in the setup at all.
As you have already confirmed that the resolution of MTA HELO (“ip:mail.mydomain.com”) works perfect, then there is not much you could do on your server. Then, it must be Gmail account specific.
In that case, you could try to debug that particular Gmail address with telnet. Then, you may see the debug output to find where the problem could be. Do you know how to do this with exim4?
I’m able to send empty letters to several gmail accounts, but emails with files and content goes to msglog and giving:
1md5Pv-000lPZ-CW H=gmail-smtp-in.l.google.com [108.177.127.26]: SMTP timeout after end of data (297833 bytes written): Connection timed out output to exim log.
Lets go further:
openssl s_client -state -connect postman-echo.com:443 | openssl x509 -text
openssl s_client -starttls smtp -host mail.domain.com -port 25
echo “” | openssl s_client -connect mail.domain.com:25 -starttls smtp -showcerts | openssl x509 -text
Do you see a proper transaction with your certificate?
exim -bhc 108.177.127.26
helo me
mail from:[email protected]
rcpt to:[email protected]
data
hello me
Identify where it gets trapped in ACL. It will declare “condition test failed in ACL”, when it begins to transmitt the data. It must be one of these condition that create a trap and failes the connection.
Sorry. I now read again and found that you do not have problems to receive emails from certain Gmail accounts. You have problem to deliver into specific Gmail accounts, right?
NB: I was working and not well concentrated…
Yes, that’s right. I can receive mail from any google accounts and can send to them any empty emails. But to some recipients letters with content (files) goes to msglog with errors of timeout.
This all is OK.
/var/log/exim4# host gmail.com
gmail.com has address 142.250.179.197
gmail.com has IPv6 address 2a00:1450:400e:80d::2005
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 20 alt2.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 40 alt4.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
gmail.com mail is handled by 30 alt3.gmail-smtp-in.l.google.com.
This if all fine.
telnet alt1.gmail-smtp-in.l.google.com 25
Trying 142.250.150.27…
Connected to alt1.gmail-smtp-in.l.google.com.
Escape character is ‘^]’.
220 mx.google.com ESMTP i18si3596127lfe.138 - gsmtp
ehlo foo
250-mx.google.com at your service, [5.79.69.2]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
starttls
220 2.0.0 Ready to start TLS
Connection closed by foreign host.
And exim log shows:
R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for ‘gmail.com’
Finally letters began to leave msglog with positive status. There were 6 letters in the morning, and now only 2 left. Here is full log:
2021-10-20 09:51:03 1md5RG-000lWz-ST <= [email protected] H=my-comp (WIN-G320SDD6MAF) [80.80.80.80] P=esmtpsa X=TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=no A=dovecot_plain:[email protected] S=177178 [email protected]
2021-10-20 10:01:03 1md5RG-000lWz-ST H=gmail-smtp-in.l.google.com [108.177.127.27]: SMTP timeout after end of data (179928 bytes written): Connection timed out
2021-10-20 10:09:06 1md5RG-000lWz-ST Spool file for 1md5RG-000lWz-ST is locked (another process is handling this message)
2021-10-20 10:09:43 1md5RG-000lWz-ST Spool file for 1md5RG-000lWz-ST is locked (another process is handling this message)
2021-10-20 10:11:03 1md5RG-000lWz-ST H=alt1.gmail-smtp-in.l.google.com [142.250.150.27]: SMTP timeout after end of data (179928 bytes written): Connection timed out
2021-10-20 10:21:07 1md5RG-000lWz-ST H=alt2.gmail-smtp-in.l.google.com [74.125.200.26]: SMTP timeout after end of data (179928 bytes written): Connection timed out
2021-10-20 10:31:10 1md5RG-000lWz-ST H=alt3.gmail-smtp-in.l.google.com [142.250.157.27]: SMTP timeout after end of data (179928 bytes written): Connection timed out
2021-10-20 10:34:51 1md5RG-000lWz-ST Spool file for 1md5RG-000lWz-ST is locked (another process is handling this message)
2021-10-20 10:41:11 1md5RG-000lWz-ST H=alt4.gmail-smtp-in.l.google.com [173.194.202.27]: SMTP timeout after end of data (179928 bytes written): Connection timed out
2021-10-20 10:41:11 1md5RG-000lWz-ST == [email protected] [email protected] R=dnslookup T=remote_smtp defer (110): Connection timed out H=alt4.gmail-smtp-in.l.google.com [173.194.202.27]: SMTP timeout after end of data (179928 bytes written)
2021-10-20 11:29:09 1md5RG-000lWz-ST H=gmail-smtp-in.l.google.com [108.177.127.27]: SMTP timeout after end of data (179928 bytes written): Connection timed out
2021-10-20 11:39:09 1md5RG-000lWz-ST H=alt1.gmail-smtp-in.l.google.com [142.250.150.27]: SMTP timeout after end of data (179928 bytes written): Connection timed out
2021-10-20 11:47:05 1md5RG-000lWz-ST Spool file for 1md5RG-000lWz-ST is locked (another process is handling this message)
2021-10-20 11:49:09 1md5RG-000lWz-ST Spool file for 1md5RG-000lWz-ST is locked (another process is handling this message)
2021-10-20 11:49:13 1md5RG-000lWz-ST H=alt2.gmail-smtp-in.l.google.com [74.125.200.27]: SMTP timeout after end of data (179928 bytes written): Connection timed out
2021-10-20 11:55:56 1md5RG-000lWz-ST Spool file for 1md5RG-000lWz-ST is locked (another process is handling this message)
2021-10-20 11:59:15 1md5RG-000lWz-ST H=alt3.gmail-smtp-in.l.google.com [142.250.157.27]: SMTP timeout after end of data (179928 bytes written): Connection timed out
2021-10-20 12:09:17 1md5RG-000lWz-ST H=alt4.gmail-smtp-in.l.google.com [173.194.202.27]: SMTP timeout after end of data (179928 bytes written): Connection timed out
2021-10-20 12:09:17 1md5RG-000lWz-ST == [email protected] [email protected] R=dnslookup T=remote_smtp defer (110): Connection timed out H=alt4.gmail-smtp-in.l.google.com [173.194.202.27]: SMTP timeout after end of data (179928 bytes written)
2021-10-20 12:29:09 1md5RG-000lWz-ST H=alt1.gmail-smtp-in.l.google.com [142.250.150.26]: SMTP timeout after end of data (179928 bytes written): Connection timed out
2021-10-20 12:29:14 1md5RG-000lWz-ST => [email protected] [email protected] R=dnslookup T=remote_smtp H=alt2.gmail-smtp-in.l.google.com [74.125.200.27] TFO X=TLS1.3:ECDHE_X25519__ECDSA_SECP256R1_SHA256__AES_256_GCM:256 CV=yes K C=“250 2.0.0 OK i1si2180294plt.17 - gsmtp”
2021-10-20 12:29:14 1md5RG-000lWz-ST Completed
In that case, if the mail queue only has test emails, you could execute the following:
for i in
exiqgrep -i -f; do exim -Mrm $i; done
Then try the test again. The above commands will remove all messages in the queue, to reduce the confusion. in the message before, you proved that starttls works fine but did not actually relay any message. Then you placed the output from the logfile. This means there were messages in the queue waiting to be delivered and for some unknown reason could not. here, flushing the queue is a good option to remove test messages.
Tried that already. Cleaned message queue and restarted exim4 - same story.
New mail with files stay in queue and give timeout error with gmail smtp.
VestaCP on this server worked for years, I’ve migrated to HestiaCP with clean install on Debian 11 few days ago and got this issues…
Is hostname = RDNS
You can also try nano /etc/exim4/exim4.conf.template and then replace
smtp_active_hostname=“string” with
smtp_active_hostname = ${lookup dnsdb{ptr=$sending_ip_address}{$value}{$primary_hostname}}
And then systemctl restart exim4
And then send a email
I think I found the problem and workaround:
Solution 1
Do not include the quotation marks.
Or for testing:
echo 0 > /proc/sys/ipv4/tcp_window_scaling
I did this and all my mail immediately gone.
Now when I send same letters to same client with files - server send it without any time lag.
Found it here.
Well, what a ridiculous problem!
I would not be able to share config in the sysctl.conf on my server because I use my own minimum config. But let me show you what I have:
net.ipv4.ip_nonlocal_bind = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
In there, I have everything commented and added the above.
As an alternative, you could try the above to see if it works. If yes, then I will not patch your solution in my default sysctl.conf.
I use abou 400 shell scripts to install and clone my servers with one click by executing i.sh, I programmed. After a few manual answers during the installation, I get a full clone of a totally configured system including everything, users, mail-forwards, config of nginx/exim/dovecot/apache2, etc. system configuration is also included in these install scripts framework. So that is what I have in my sysctl.conf since years and never had a problem.
I found some more info here:
So I would insert in my sysctrl.conf the following:
net.ipv4.tcp_window_scaling=0
I do not use ip6.
Same here never seen the issue before…
Becarefull with 0:
The default size of the send buffer for a TCP socket. This value overwrites the initial default buffer size from the generic global /proc/sys/net/core/wmem_default defined for all protocols. The default value is 16 kB. If larger send buffer sizes are desired, this value should be increased (to affect all sockets). To employ large TCP windows, the /proc/sys/net/ipv4/tcp_window_scaling must be set to a nonzero value (default).
I know that, learned all info about this setting before disabling, but it worked.
And I don’t know why it doesn’t work with default tcp settings.
I added in my sysctl.conf for testing, if something similar happens. Thanks, Eris you spotted a lacuna that may open dorrs to black magic. I will remove this. Hackers may love the null value and send large packets.
The problem is somewhere in firewall.
I’ve disabled it and set tcp_window_scaling back to 1.
And it worked. Tried several times:
tcp_window_scaling 1 and firewall on - message stay in queue and smtp gmail timeout.
tcp_window_scaling 0 and firewall on - message goes away
tcp_window_scaling 1 and firewall off - message goes away
Firewall settings are completely default!
Are you using VPS / OpenVZ by accident?
Yes, it’s QEMU/KVM guest. Virtual machine with bridged network interface.