Polling POP3: compreendendo o log do dovecot

Estou me atualizando sobre os recursos de pesquisa POP3 e resposta por e-mail e começando a entendê-los.

Mas estou com dificuldades para explicar o que nosso servidor POP3 está registrando no log quando o Discourse se conecta. Você poderia me ajudar a explicar as linhas emparelhadas RETR/access registradas no log do servidor POP3 toda vez que o Discourse se conecta a ele? Isso acontece, como esperado pelo valor de pop3 polling period mins, a cada 5 minutos.

No arquivo anexado (21,2 KB), as linhas registradas desde a ativação de ambos os recursos e a primeira ação de pesquisa.

Obrigado pela ajuda!

(Como isso é uma pergunta sobre Discourse e não sobre Dovecot?)

Isso simplesmente significa que o Discourse está recuperando os e-mails em sua caixa de correio, um por um.

Hesito entre perguntar aqui e procurar ajuda no fórum do Dovecot. Perguntei aqui porque é o Discourse que consulta o e-mail do servidor. Sua resposta me ajudou a igualar o número de “linhas pareadas” com o número de mensagens disponíveis no servidor. Ainda não entendo por que às vezes o número de linhas pareadas é exatamente o número de mensagens na caixa de entrada, mas outras vezes é apenas 36.

Estou procurando agora na comunidade Dovecot por mais informações: preciso de uma explicação completa sobre o log para poder usar os recursos POP3 do Discourse.

Muito obrigado pela sua ajuda.

1 curtida

Tem certeza de que o 36 é causado pelo Discourse e não por exemplo pelo roundcube ou outro cliente de e-mail que está recuperando e-mails página por página?

Tão certo quanto um novato usando o verão para aprimorar suas habilidades pode ser! Obrigado por considerar o problema.

Acho que o RoundCube está usando IMAP aqui. O novo anexo (9,8 KB) inclui uma série n=36. Ele se reproduz a cada 5 minutos. É principalmente por isso que estou suspeitando que esteja relacionado ao Discourse. Ainda não consigo entender quando n é igual ao número de mensagens na caixa de entrada da conta da premissa.

Obrigado!

Estou mais seguro sobre a origem e, após ler o RFC 1939 e conseguir acessar rails c para trabalhar com a biblioteca net/pop pelo menos para algumas ações básicas.

[10] pry(main)> Net::POP3.enable_ssl(OpenSSL::SSL::VERIFY_NONE)
=> {:verify_mode=>0}
[11] pry(main)> pop = Net::POP3.new('x.y.z')
=> #<Net::POP3 x.y.esz open=false>
[12] pry(main)> pop.start('premises', 'xxxxxxxxx')
=> #<Net::POP3 x.y.z: open=true>
[13] pry(main)> pop.n_mails()
=> 103

O que não consigo explicar é por que alguns ciclos de polling leem apenas 36 mensagens. O último acesso é sempre UID=36.

19 de ago 15:46:00 igfae dovecot: pop3(premises): Debug: Mailbox INBOX: Opened mail UID=36 because: access
19 de ago 15:46:00 igfae dovecot: pop3(premises): Debug: Mailbox INBOX: Opened mail UID=36 because: RETR

Este número não foi modificado, apesar de agora haver mais mensagens na conta.

Você poderia me ajudar a encontrar uma explicação para esse comportamento? A equipe de segurança do nosso centro não gosta de ter software em execução gerando logs que não conseguimos explicar! Obrigado!

No entanto, por mais tentador que isso seja - já que eu também não gosto de coisas que não entendo - acho que é um exercício inútil, pois não há um problema real.

Eu verifiquei rapidamente o código-fonte da última vez e não encontrei nada lá.
Sugiro que você diminua o nível de log…

Logging é outro tópico sobre o qual tenho muito a aprender!

No arquivo atual /var/log/maillog do nosso servidor de e-mail, 30644 de 36467 linhas são relacionadas ao Dovecot. O Discourse é o único serviço que usa Dovecot em nossa organização. Embora muitas pessoas estejam de férias, 84% dos registros retratam a atividade de e-mail do Discourse.

Não tenho nenhum controle sobre o que o servidor de e-mail registra. Só posso lê-lo. Assim, só pude modificar quais informações o Discourse/Dovecot estão enviando. A maioria das linhas inclui Debug. Portanto, acho que a configuração de login em nossa instância do Discourse está enviando informações de depuração para o servidor de e-mail.

Como eu poderia modificar esse comportamento?

Aceite minhas desculpas antecipadamente se eu tiver um claro mal-entendido de como o processo de log funciona! Obrigado!

Não, o servidor de e-mail está configurado para registrar em nível de “debug”.

O que está acontecendo é o seguinte:

  • a instância do dovecot em sua organização foi configurada para registrar no nível de depuração. O nível de depuração é destinado à solução de problemas avançada e requer um conhecimento profundo do funcionamento do software dovecot. Como não há problema, não há necessidade de solução de problemas e, como não há necessidade de solução de problemas, o nível de log pode ser definido para um nível inferior (menos detalhado).
  • Sua equipe de segurança em seu centro reclama que não entende os logs. Isso ocorre porque a compreensão desses logs requer um conhecimento profundo do funcionamento do software dovecot, o que eles não têm.

Daí a solução: a equipe que executa o software dovecot deve alterar o nível de log.

Isso não é algo sobre o qual eles devam reclamar para as pessoas que usam o software dovecot (ou seja, você). É algo que eles ou seus colegas de equipe fizeram.

Eles fizeram isso! O log está muito mais limpo e informativo agora.

Muito obrigado pela sua explicação. É muito mais fácil dialogar com uma boa descrição e análise da situação. Posso entender todas as preocupações de segurança, pois enfrentamos algumas situações difíceis nos últimos dois anos. Aceito o exercício de lutar por uma explicação, mas, sem sua ajuda e a ajuda de outros voluntários aqui e ali, não será possível para pessoas como eu, com poucas habilidades de TI, usar e promover o uso de ótimas ferramentas como o Discourse.

Além disso, agora passarei para outras dúvidas relacionadas às configurações de e-mail. Muito obrigado!

1 curtida