Sto recuperando le funzionalità di polling POP3 e replay via email e sto iniziando a capirle.
Ma sto avendo difficoltà a spiegare cosa registra il nostro server POP3 nel log quando Discourse si connette. Potresti aiutarmi a spiegare le righe accoppiate RETR/access registrate nel log del server POP3 ogni volta che Discourse si connette ad esso? Succede, come previsto dal valore di pop3 polling period mins, ogni 5 minuti.
Nel file allegato (21,2 KB), le righe registrate dall’attivazione di entrambe le funzionalità e dalla prima azione di polling.
Esito tra chiedere qui e cercare aiuto sul forum di Dovecot. Ho chiesto qui perché Discourse esegue il polling delle email dal server. La tua risposta mi ha aiutato a far corrispondere il numero di “righe accoppiate” con il numero di messaggi disponibili sul server. Non capisco ancora perché a volte il numero di righe accoppiate sia esattamente il numero di messaggi nella casella di posta, ma altre volte sia solo 36
Sto cercando ora nella community di Dovecot per maggiori informazioni: ho bisogno di una spiegazione completa del log per poter utilizzare le funzionalità POP3 di Discourse.
Sei sicuro che 36 sia causato da Discourse e non, ad esempio, da Roundcube o da un altro client di posta elettronica che recupera le email pagina per pagina?
Certo quanto può esserlo un principiante che usa l’estate per migliorare le proprie capacità! Grazie per aver preso in considerazione il problema.
Penso che RoundCube stia usando IMAP qui. Il nuovo allegato (9,8 KB) include una serie n=36. Si ripete ogni 5 minuti. Questo è principalmente il motivo per cui sospetto sia correlato a Discourse. Non sono ancora in grado di capire quando n è uguale al numero di messaggi nella casella di posta dell’account di premise.
Sono ora più sicuro riguardo all’origine e dopo aver letto RFC 1939 e aver potuto accedere a rails c per lavorare con la libreria net/pop almeno per alcune azioni di base.
Ciò che non riesco a spiegare è perché alcuni cicli di polling leggono solo 36 messaggi. L’ultimo accesso è sempre UID=36.
19 ago 15:46:00 igfae dovecot: pop3(premises): Debug: Mailbox INBOX: Aperta mail UID=36 perché: access
19 ago 15:46:00 igfae dovecot: pop3(premises): Debug: Mailbox INBOX: Aperta mail UID=36 perché: RETR
Questo numero non è stato modificato nonostante ci siano ora più messaggi nell’account.
Potreste aiutarmi a trovare una spiegazione a questo comportamento? Il personale di sicurezza del nostro centro non ama avere software in esecuzione che genera log che non riusciamo a spiegare! Grazie!
Tuttavia, per quanto allettante possa essere - dato che nemmeno a me piacciono le cose che non capisco - penso che sia un esercizio inutile poiché non c’è un problema reale.
Ho controllato rapidamente il codice sorgente l’ultima volta e non ho trovato nulla lì.
Suggerisco di abbassare il livello di log…
Anche il logging è un altro argomento su cui ho molto da imparare!
Nell’attuale file /var/log/maillog del nostro server di posta, 30644 righe su 36467 sono relative a Dovecot. Discourse è l’unico servizio che utilizza Dovecot nella nostra organizzazione. Sebbene molte persone siano in vacanza, l’84% dei record raffigura l’attività email di Discourse.
Non ho alcun controllo su ciò che il server di posta registra. Posso solo leggerlo. Pertanto, potrei solo modificare le informazioni che Discourse/Dovecot stanno inviando. La maggior parte delle righe include Debug. Quindi, immagino che la configurazione di login nella nostra istanza di Discourse stia inviando informazioni di debug al server di posta.
Come potrei modificare questo comportamento?
Accetta in anticipo le mie scuse se ho un chiaro malinteso su come funziona il processo di logging! Grazie!
No, il server di posta è configurato per registrare a livello di “debug”.
Quello che sta succedendo è il seguente:
l’istanza dovecot nella tua organizzazione è stata configurata per registrare a livello di debug. Il livello di debug è destinato alla risoluzione avanzata dei problemi e richiede una profonda conoscenza del funzionamento del software dovecot. Poiché non c’è nessun problema, non c’è bisogno di risolvere problemi e poiché non c’è bisogno di risolvere problemi, il livello di log può essere impostato su un livello inferiore (meno verboso).
Il tuo personale di sicurezza nel tuo centro si lamenta del fatto che non capisce i log. Questo perché la comprensione di questi log richiede una profonda conoscenza del funzionamento del software dovecot, che loro non hanno.
Quindi la soluzione: il personale che gestisce il software dovecot dovrebbe cambiare il livello di log.
Questa non è una cosa di cui dovrebbero lamentarsi con le persone che utilizzano il software dovecot (cioè tu). È qualcosa che loro o i loro colleghi hanno fatto.
Ce l’hanno fatta! Il log è molto più pulito e informativo ora.
Grazie mille per la tua spiegazione. È molto più facile dialogare con una buona descrizione e analisi della situazione. Posso capire tutte le preoccupazioni sulla sicurezza, dato che abbiamo affrontato alcune situazioni difficili negli ultimi due anni. Accetto l’esercizio di lottare per una spiegazione, ma, senza il tuo aiuto e l’aiuto di altri volontari qua e là, non sarebbe possibile per persone come me, con poche competenze informatiche, utilizzare e promuovere l’uso di ottimi strumenti come Discourse.
Inoltre, ora passerò ad altri dubbi relativi alle impostazioni delle email. Grazie mille!