SMTP Net::ReadTimeout without relation to net or login problems - SMTP host is just slow

Feature
1

Hello,

since view weeks sending mail from my Discourse instance fails. The SMTP settings are unchanged, curl test is still working but notably slow. The smtp server from our hoster (that we need to send mails with) has a consistent send time of 7 seconds.

cat testmail | curl -vvv --url 'smtp://smtp.<HOST>:587' --mail-from mail@<DOMAIN> --mail-rcpt <ME> --user "mail@<DOMAIN>:<PW>" -T -

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying <IP>...
* Connected to smtp.<HOST> (<IP>) port 587 (#0)
< 220 mailproxy1.<HOST> Dovecot ready.
> EHLO ecm2
< 250-mailproxy1.<HOST>
< 250-8BITMIME
< 250-AUTH PLAIN LOGIN
< 250-BURL imap
< 250-ENHANCEDSTATUSCODES
< 250-SIZE
< 250-STARTTLS
< 250 PIPELINING
> AUTH PLAIN
< 334 
> xxxxxx=
  0     0    0     0    0     0      0      0 --:--:--  0:00:06 --:--:--     0< 235 2.7.0 Authentication successful
  0     0    0     0    0     0      0      0 --:--:--  0:00:07 --:--:--     0> MAIL FROM:<mail@<DOMAIN>>
< 250 2.1.0 Ok
> RCPT TO:<<ME>>
< 250 2.1.5 Ok
> DATA
< 354 End data with <CR><LF>.<CR><LF>
} [89 bytes data]
100    89    0     0    0    89      0     11 --:--:--  0:00:07 --:--:--    20< 250 2.0.0 Ok: queued as 356C3288C85
100    89    0     0    0    89      0     11 --:--:--  0:00:07 --:--:--    26
* Connection #0 to host smtp.<HOST> left intact

I compared this to our internal mail server with <1 second per mail. The 7 seconds from the mail hoster would be no real problem, but I was unable to identify a setting where to lift the (seemingly hard-coded?) 5 seconds timeout. The open_timeout and, as it seems to me, more relevant read_timeout is also visible in the test interface at /admin/email:

screenshots
screenshots707×842 34.6 KB

  • Timings in the docker app container is identical to a local test or a test on the docker host.
  • cURL sent mails are delivered correctly (after the 7 seconds wait + the blink of an eye).
  • For privacy reasons, the usual workarounds like sendgrid, mailgun etc. are sadly no option.
  • Maybe a switch to ActionMailer 7.0.x triggerd this problem for me?

Thank you for any idea how to configure read_timeout.

1 Like
2

For that is necessary to add those new settings on

So it looks like

  if GlobalSetting.smtp_address
    settings = {
      address: GlobalSetting.smtp_address,
      port: GlobalSetting.smtp_port,
      domain: GlobalSetting.smtp_domain,
      user_name: GlobalSetting.smtp_user_name,
      password: GlobalSetting.smtp_password,
      authentication: GlobalSetting.smtp_authentication,
      enable_starttls_auto: GlobalSetting.smtp_enable_start_tls,
+     open_timeout: GlobalSetting.smtp_open_timeout,
+     read_timeout: GlobalSetting.smtp_read_timeout
    }

Can you make a pull request with the changes?

2 Likes
3

Hey @Falco,

thank you for your quick reply. You are correct, these changes are effective:

screenshot

  • The new timeout from app.yml are visible
  • Mails can be sent.

Since my Ruby is virtualy non-existent I will try my best to prepare the pull request and am already very thankful for your help and Discourse in general.

Kind regards

Roland

2 Likes
4

The PR is online: Allow configuration of smtp timeout settings by rolandkoller · Pull Request #17863 · discourse/discourse · GitHub

I would be grateful for any input on how/if I can improve the PR.

4 Likes
5

We just need a CLA signature in the PR for us to merge it.

2 Likes
6

Sorry, had an extended weekend. Done.

7

FWIW They do this on purpose to discourage spammers. Most automated spam tools also have a 5 second timeout.

1 Like
8

I expect exactly this, as the delay on the SMTP server side is too homogeneous. So the fix suggest by @Falco which is now in PR#17863 may be relevant for more users.

There is an error in the core frontend (Headless Firefox) unit test. I am far from knowing what is going on, but I would not expect this to be triggert by our change here.

1 Like
9

Thanks for the PR and testing. It’s now merged.

1 Like
10

This topic was automatically closed after 4 days. New replies are no longer allowed.