SMTP Net::ReadTimeout sem relação com problemas de rede ou login - o host SMTP está apenas lento

Funcionalidade
1

Olá,

há algumas semanas o envio de e-mails da minha instância Discourse falha. As configurações SMTP não foram alteradas, o teste com curl ainda funciona, mas notavelmente lento. O servidor SMTP do nosso hoster (que precisamos para enviar e-mails) tem um tempo de envio consistente de 7 segundos.

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

Comparei isso com nosso servidor de e-mail interno com menos de 1 segundo por e-mail. Os 7 segundos do hoster de e-mail não seriam um problema real, mas não consegui identificar uma configuração para aumentar o tempo limite (aparentemente codificado?) de 5 segundos. O open_timeout e, ao que me parece, o mais relevante read_timeout também são visíveis na interface de teste em /admin/email:

screenshots
screenshots707×842 34.6 KB

  • Os tempos no contêiner do aplicativo Docker são idênticos a um teste local ou a um teste no host Docker.
  • E-mails enviados pelo cURL são entregues corretamente (após os 7 segundos de espera + um piscar de olhos).
  • Por motivos de privacidade, as soluções alternativas usuais como SendGrid, Mailgun, etc. infelizmente não são uma opção.
  • Talvez uma mudança para ActionMailer 7.0.x tenha desencadeado esse problema para mim?

Obrigado por qualquer ideia sobre como configurar read_timeout.

1 curtida
Cannot send email - problem with port 465
2

Para isso, é necessário adicionar essas novas configurações em

Assim, fica assim

  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
    }

Você pode fazer um pull request com as alterações?

2 curtidas
Extending SMTP timeout
Issues with mail sending to SMTP relay
Severe Email Issue since last update a couple days ago - 3.4.0.beta4-dev
3

Olá @Falco,

Obrigado pela sua rápida resposta. Você está correto, essas alterações são eficazes:

screenshot
screenshot571×215 8.85 KB

  • O novo tempo limite de app.yml está visível
  • E-mails podem ser enviados.

Como meu conhecimento de Ruby é praticamente inexistente, farei o meu melhor para preparar o pull request e já estou muito grato pela sua ajuda e pelo Discourse em geral.

Atenciosamente,

Roland

2 curtidas
4

O PR está online: Allow configuration of smtp timeout settings by rolandkoller · Pull Request #17863 · discourse/discourse · GitHub

Ficaria grato por qualquer contribuição sobre como/se posso melhorar o PR.

4 curtidas
5

Precisamos apenas de uma assinatura do CLA no PR para que possamos mesclá-lo.

2 curtidas
6

Desculpe, tive um fim de semana prolongado. Feito.

7

Para informação, eles fazem isso de propósito para desencorajar spammers. A maioria das ferramentas automatizadas de spam também tem um tempo limite de 5 segundos.

1 curtida
8

Eu espero exatamente isso, pois o atraso no lado do servidor SMTP é muito homogêneo. Portanto, a correção sugerida por @Falco, que agora está em PR#17863, pode ser relevante para mais usuários.

Há um erro no teste unitário core frontend (Headless Firefox). Estou longe de saber o que está acontecendo, mas não esperaria que isso fosse acionado por nossa mudança aqui.

1 curtida
9

Obrigado pelo PR e pelos testes. Foi mesclado.

1 curtida
10

Este tópico foi automaticamente fechado após 4 dias. Novas respostas não são mais permitidas.