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.
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.
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.
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.
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!