POP3 폴링과 이메일 재생성(replaying by email) 기능을 익히고 그 원리를 이해하기 시작했습니다.
하지만 Discourse가 연결될 때 우리의 POP3 서버가 로그에 기록하는 내용을 설명하는 데 어려움을 겪고 있습니다. Discourse가 POP3 서버에 연결될 때마다 로그에 기록되는 RETR/access 쌍의 줄에 대해 설명해 주실 수 있을까요? 이는 pop3 polling period mins 값에 기대대로 5분마다 발생하고 있습니다.
첨부 파일 (21.2 KB)에는 두 기능이 활성화된 시점부터 첫 번째 폴링 작업까지 기록된 줄들이 포함되어 있습니다.
도와주셔서 감사합니다!
(이게 왜 Discourse 질문이지, Dovecot 질문이 아니고?)
그냥 Discourse가 메일함의 메일들을 하나씩 가져온다는 뜻입니다.
여기에서 질문할지, 아니면 Dovecot 포럼에서 도움을 받을지 고민하고 있습니다. 서버에서 Discourse가 이메일을 폴링하기 때문에 여기에서 질문했습니다. 여러분의 답변 덕분에 서버에 있는 메시지 수와 "페어링된 줄"의 수를 일치시킬 수 있었습니다. 하지만 왜 때로는 페어링된 줄의 수가 받은 편지함의 메시지 수와 정확히 일치하고, 다른 때는 36으로 고정되는지 아직 이해하지 못했습니다.
이제 Dovecot 커뮤니티에서 더 많은 정보를 찾고 있습니다: Discourse의 POP3 기능을 사용하려면 로그에 대한 전체적인 설명이 필요합니다.
도움 주셔서 정말 감사합니다.
36개라는 숫자가 Discourse 때문이 아니라, 페이지 단위로 메일을 가져오는 Roundcube나 다른 이메일 클라이언트 때문이라고 확신하십니까?
여름을 이용해 실력을 키우려는 초보자가 가질 수 있는 만큼 확신합니다! 문제를 고려해 주셔서 감사합니다.
RoundCube가 여기서 IMAP를 사용하는 것 같습니다. 새 첨부 파일 (9.8 KB)에는 n=36 시리즈가 포함되어 있습니다. 이는 5분마다 재현됩니다. 이것이 주로 Discourse 관련 문제라고 추측하는 이유입니다. 아직 n이 premise 계정의 받은 편지함 메시지 수와 같을 때를 이해하지 못하고 있습니다.
감사합니다!
이제 출처에 대해 더 확신이 생겼습니다. RFC 1939를 읽고 rails c에 접근하여 net/pop 라이브러리로 적어도 몇 가지 기본 작업을 수행할 수 있게 되었습니다.
[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
설명할 수 없는 점은 왜 일부 폴링 주기에서는 메시지가 36개만 읽히는지입니다. 마지막 접근은 항상 UID=36입니다.
Aug 19 15:46:00 igfae dovecot: pop3(premises): Debug: Mailbox INBOX: Opened mail UID=36 because: access
Aug 19 15:46:00 igfae dovecot: pop3(premises): Debug: Mailbox INBOX: Opened mail UID=36 because: RETR
계정에 이제 더 많은 메시지가 있음에도 불구하고 이 숫자는 변경되지 않았습니다.
이러한 동작에 대한 설명을 찾는 데 도움을 주실 수 있을까요? 저희 센터의 보안 담당자들이 설명할 수 없는 로그를 생성하는 소프트웨어가 실행되는 것을 좋아하지 않습니다! 감사합니다!
이유를 모르겠으니 그냥 넘어가자는 유혹이 크긴 합니다. 저도 이해하지 못하는 것을 좋아하진 않으니까요. 하지만 실제로 문제가 없는 상황에서 이 작업은 무의미하다고 생각합니다.
마지막으로 소스 코드를 빠르게 확인해 보았지만, 거기서도 아무것도 찾을 수 없었습니다.
로그 레벨을 낮추는 것을 제안합니다…
로깅은 제가 배울 것이 많은 또 다른 주제입니다!
현재 메일 서버의 /var/log/maillog 파일에서 총 36,467줄 중 30,644줄이 Dovecot과 관련되어 있습니다. 저희 조직에서 Dovecot을 사용하는 유일한 서비스는 Discourse입니다. 많은 사람들이 휴가 중임에도 불구하고, 기록의 84%가 Discourse 이메일 활동과 관련된 것으로 나타났습니다.
메일 서버가 무엇을 기록하는지에 대해서는 제가 전혀 통제할 수 없습니다. 읽기만 할 수 있을 뿐입니다. 따라서 제가 수정할 수 있는 것은 Discourse/Dovecot이 메일 서버로 보내는 정보뿐입니다. 대부분의 줄에 Debug가 포함되어 있습니다. 그래서 저희 Discourse 인스턴스의 로그인 설정이 메일 서버로 디버그 정보를 보내고 있는 것으로 추정됩니다.
이 동작을 어떻게 수정할 수 있을까요?
로깅 프로세스가 어떻게 작동하는지에 대해 명확한 오해를 하고 있다면 미리 사과드립니다! 감사합니다!
아니요, 메일 서버가 “debug” 레벨로 로그를 기록하도록 구성되어 있습니다.
현재 일어나고 있는 상황은 다음과 같습니다.
따라서 해결책은 다음과 같습니다: dovecot 소프트웨어를 관리하는 직원이 로그 레벨을 변경해야 합니다.
이것은 dovecot 소프트웨어를 사용하는 사람들(즉, 여러분)에게 불만을 제기해야 할 문제가 아닙니다. 이것은 그들이나 그들의 동료 직원이 수행한 작업입니다.
그들이 그렇게 했습니다! 이제 로그가 훨씬 깔끔하고 유용한 정보를 제공합니다.
설명해 주셔서 진심으로 감사합니다. 상황을 잘 설명하고 분석해 주시면 대화하기가 훨씬 수월합니다. 지난 몇 년간 어려운 상황을 여러 번 겪었기 때문에 모든 보안 우려를 이해합니다. 설명을 구하기 위한 고충을 받아들이지만, 여러분과 여기저기서 자원봉사를 해 주시는 분들의 도움 없이는 저처럼 IT 기술이 부족한 사람들이 Discourse와 같은 훌륭한 도구를 사용하고 그 사용을 장려하는 것은 불가능할 것입니다.
또한, 이제 이메일 설정과 관련된 다른 질문으로 넘어가겠습니다. 정말 감사합니다!