Sending mails by SMTP is very slow

Basti-Fantasti

Hi @all

First of all, thanks for this great mailcow dockerized project!
I have the problem that sending mails by SMTP takes a very long time.

I found several threads regarding the same problem but no solution for my problem.

I’m connecting via SMTP on port 465 SSL/TLS (so not Port 25 to avoid this problem)
IPv6 is not enabled and I have no public IPv6 address, so I have no AAAA record for my mail server and the PTR record is only set for the IPv4 address
Sending mails is always slow independent of using
- SoGo
- Thunderbird on my client PC
- GMail App on Android
- Server in our company running a CRM and sending mails using PHP (here there’s sometimes even a timeout while sending)

Here’s the postfix log. This is recorded while sending an email using Thunderbird.
It shows a delay of approx. 7sec before processing the email further…

16.08.2021, 08:56:27 info C164F343F7: removed 16.08.2021, 08:56:27 info C164F343F7: to=<receivermail@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.140.27]:25, delay=13, delays=11/0.02/1.2/0.45, dsn=2.0.0, status=sent (250 2.0.0 OK 1629096987 3si10838896wry.379 - gsmtp) 16.08.2021, 08:56:26 info Trusted TLS connection established to gmail-smtp-in.l.google.com[74.125.140.27]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 16.08.2021, 08:56:26 info connect to gmail-smtp-in.l.google.com[2a00:1450:400c:c08::1b]:25: Network is unreachable 16.08.2021, 08:56:25 info disconnect from mail.my.tld[1.2.3.4] ehlo=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=6 16.08.2021, 08:56:25 info C164F343F7: from=<sender@my.tld>, size=3732, nrcpt=1 (queue active) 16.08.2021, 08:56:18 info C164F343F7: message-id=<644e4cb4-e5f4-7349-c21c-a932b599211e@my.tld> 16.08.2021, 08:56:18 info C164F343F7: replace: header Received: from [172.21.0.36] (mail.my.tld [1.2.3.4])??(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)?? key-exchange X25519 server-signature RSA-PSS (2048 bits))??(No client cer from mail.my.tld[1.2.3.4]; from=<sender@my.tld> to=<receivermail@gmail.com> proto=ESMTP helo=<[172.21.0.36]>: Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id C164F343F7??for <receivermail@gmail.com>; Mon, 16 Aug 2021 08:56:14 +0200 (CEST) 16.08.2021, 08:56:18 info C164F343F7: client=mail.my.tld[1.2.3.4], sasl_method=PLAIN, sasl_username=sender@my.tld 16.08.2021, 08:56:14 info Anonymous TLS connection established from mail.my.tld[1.2.3.4]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) 16.08.2021, 08:56:14 info connect from mail.my.tld[1.2.3.4] 16.08.2021, 08:56:03 info statistics: max cache size 1 at Aug 16 08:52:37

Any help is greatly appreciated.

Best regards
Bastian

reventor

Basti-Fantasti
Did you find a solution? I have the same issue.

Mikes

I have the same problem, even though I just updated mailcow to latest version. How can this be fixed?! Obviously the problem is still there. I have a client with a webshop, when an order is made, an email is sent (not queued) and the UI is waiting for the email to be sent… indefinitely. The buyers who made a purchase are all waiting for the confirmation emails to be dispatched and it sometimes times out.. This must be fixed!

reventor

From my understanding this is intentional. It’s part of the email servers security machanism to accept incoming sending requests only after some time. If you send another email right after the first one this will be sent much quicker. 8 seconds vs 2 seconds waiting time. I have also noticed this behavior with email sending platforms, hence i dont think there is a fix, its normal behavior for an email server.
The way to avoid the problem is to tell the sending application not to wait for confirmation from the email server that the email got sent. Then the UI would just move on, the client sees the order is accepted and by that time the email should get through as well.

DocFraggle

I guess you are talking about the greylisting feature of rspamd. https://rspamd.com/doc/modules/greylisting.html

You could turn that off (but receive more SPAM mails then):

https://docs.mailcow.email/manual-guides/Rspamd/u_e-rspamd-disable-greylisting/

Or you could whitelist your web shop’s sending IP address:

https://docs.mailcow.email/manual-guides/mailcow-UI/u_e-mailcow_ui-bl_wl/

reventor

I’m not sure it has to do with rspamd. It’s not about revieceing emails, its about a delay in sending emails.

1) The webshop sends an order confirmation to the customer.
2) The Server recieves this request but waits
3) 8-10s pass without anthing happen - the webshop waits for sending confirmation
4) Email gets sent out from the server to the customer.
5) Webshop shows send confirmation message, “thanks for purchase, we sent you an email”

So what we try to elimitate is No 3). This waiting time where nothing happens.

DocFraggle

reventor So if I understand your case you are using mailcow as the mail relay server for your webshop? Did you try whitelisting it in mailcow? Or configure authentication for SMTP in your web shop system?

esackbauer

See this thread, the same problem:
https://community.mailcow.email/d/3071-smtp-transaction-delay-are-slowing-down-post-on-my-forums

Please add the webshop IP address to the postscreen filter:
https://docs.mailcow.email/manual-guides/Postfix/u_e-postfix-postscreen_whitelist/?h=posts

DocFraggle

esackbauer Ah, wrong link in my post above, thanks @esackbauer !