SMTP Net::ReadTimeout без связи с проблемами сети или входа — SMTP-хост просто медленный

Здравствуйте,

в течение нескольких недель отправка писем с моего экземпляра Discourse не удаётся. Настройки SMTP не менялись, тест с помощью curl всё ещё работает, но заметно медленно. SMTP-сервер нашего хостинг-провайдера (через который мы должны отправлять письма) имеет постоянное время отправки в 7 секунд.

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

Я сравнил это с нашим внутренним почтовым сервером, где отправка занимает менее 1 секунды на письмо. 7 секунд от хостинг-провайдера не были бы большой проблемой, но я не смог найти настройку, позволяющую увеличить (по-видимому, жёстко заданный?) таймаут в 5 секунд. Параметры open_timeout и, как мне кажется, более релевантный read_timeout, также отображаются в тестовом интерфейсе по адресу /admin/email:

  • Время выполнения в контейнере Docker совпадает с результатами локального теста или теста на хосте Docker.
  • Письма, отправленные через cURL, доставляются корректно (после ожидания 7 секунд + мгновение).
  • По соображениям конфиденциальности, обычные обходные пути, такие как SendGrid, Mailgun и т. д., к сожалению, не подходят.
  • Возможно, переход на ActionMailer версии 7.0.x стал причиной этой проблемы?

Буду благодарен за любые идеи о том, как настроить read_timeout.

1 лайк

Для этого необходимо добавить эти новые настройки в

Так что это будет выглядеть так:

  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
    }

Можете ли вы создать pull request с этими изменениями?

2 лайка

Привет, @Falco,

спасибо за быстрый ответ. Вы правы, эти изменения вступили в силу:

  • Новые таймауты из app.yml видны
  • Отправка писем работает.

Поскольку мои знания Ruby практически равны нулю, я сделаю всё возможное, чтобы подготовить pull request, и уже сейчас выражаю вам огромную благодарность за вашу помощь и за Discourse в целом.

С уважением,

Роланд

2 лайка

Pull Request доступен по ссылке: Allow configuration of smtp timeout settings by rolandkoller · Pull Request #17863 · discourse/discourse · GitHub

Буду признателен за любые предложения о том, как или можно ли улучшить этот PR.

4 лайка

Нам нужна только подпись CLA в PR, чтобы мы могли его слить.

2 лайка

Извините, были длинные выходные. Готово.

Кстати, они делают это намеренно, чтобы отпугнуть спамеров. Большинство автоматизированных инструментов для спама также имеют тайм-аут 5 секунд.

1 лайк

Я ожидаю именно этого, поскольку задержка на стороне SMTP-сервера слишком однородна. Поэтому исправление, предложенное @Falco и которое сейчас находится в PR#17863, может быть актуально для большего числа пользователей.

В модульном тесте core frontend (Headless Firefox) возникла ошибка. Я далеко не знаю, что происходит, но не ожидал, что это будет вызвано нашим изменением здесь.

1 лайк

Спасибо за PR и тестирование. Теперь он слит.

1 лайк

Эта тема была автоматически закрыта через 4 дня. Новые ответы больше не принимаются.