I have 3 users testing NethServer for the last 4 months or so, and everything has been working perfectly.
They are using WebTop for email, and the POP3 Connector is pulling email off of our main email server using IMAP.
Now, since last Sunday, 1 user has had his emails disappearing. The worst part is he has been on vacation since Monday, and did not notice he was getting no email until today. They are being pulled of our main server, but they are not showing up in the users inbox. The other 2 users are still working fine.
I assume the emails are somewhere, at least I hope, but how do I tell, I cannot see in the logs where it says where the emails are moved to.
EDIT: There is nothing in maillog for this user when the email is retrieved with pop3 connector, the setting is ādelete downloaded messages Immediatelyā, so the mail is deleted off of our main server, but the messages donāt seem to be moved anywhere. If this is a bug in Nethserver/Getmail it is a bad one, as all emails seem lost.
You may check if they are being pulled off by Nethserver when searching for āHOSTNAME getmailā or ādovecot-ldaā in logviewer.
You should get something like Aug 23 10:40:10 server getmail: msg 1212/1212 (114662 bytes) msgid 1201982220/22009 from <somesenderaddress@outside> delivered to MDA_external command dovecot-lda ()
The account may also be set on a mobile or laptop the user used when he was on vacation, so the mails may be there, just a case I had.
I canāt tell if this is for this user, but I am guessing it is, what would gause to be ānot retrievedā, and then deleted.
I deleted this user in the Pop3 connector in the Nethserver webui, checked that the .cfg file was deleted, and recreated the pop3 connection for the user (did not set to ādelete immediatelyā), and the emals are still not being delivered.
Next step, I changed the working one from the other account, to deliver that users email to the user from the non working users, and they are not delivered. So, it seems like the actual user it is being delivered to is the issue. This user can receive email that are locally sent withing NS using WebTop though.
Well, that seemed to work, I switched from IMAP to POP3, started working, tested it for a bit, and then switched back to IMAP, and still works. So, workaround, but I donāt understand this. I deleted the user, and re-added the IMAP connection, and that didntā work, but switching didā¦ has to be a bug. And, my other 2 users didnāt stop working, and one uses IMAP, other POP3.
Me too. Please, maybe you can provide some of the old backuped files like /etc/cron.d/getmail and /var/lib/nethserver/db/getmail so we can try to find the config error. The error is very bad because mails were sent to nirvana and this is not even recognized, except of searching for ānot retrieved (seen), deletedā in logviewer.
Iāve gone through your logfiles and thatās my result:
You used localmail.domain.tld and mail.domain.tld as pop/imap mailservers in your var-lib-nethserver-db-getmail, but only mail.domain.tld has pop/imap ports open, so I think localmail.domain.tld is wrong.
You mixed using name@domain.tld and only name in var-lib-nethserver-db-getmail.
User Sam exists in var-lib-nethserver-db-getmail but not in etc-cron.d-getmail.
Check existence of the files /var/lib/getmail/*@domain.tld.cfg found in etc-cron.d-getmailā¦
reuse of message uid / bad uid assignment: a new message having the same mailbox msgid (uid) as another one already seen/retrieved (e.g. error on mail provider resets the next uid index?)
ā¦
As a kind of a teardown, and trying to understand it myself:
The message was retrieved in the past (seen), therefore getmail considers (as per read_all option) thereās no need to retrieve it again. Then itās deleted, as per the configured options.
Maybe the event was logged:
grep -B1 '1092066676/182724' /var/log/maillog* # if sharing the output, make sure to anonymize 'msgid=<xxx@xxx>'
getmail msgid: IMAP message ID generated from the mailbox context (e.g. 1092066676/182724 having the INBOX as context)
mailbox timestamp (UIDVALIDITY):1092066676
message number (UID): 182724
Note: for POP3 the format could differ (e.g. UID182724-1092066676)
seen: message already retrieved:
grep -a '1092066676/182724' /var/lib/getmail/oldmail*
If found, the output (for IMAP) could look like {uidvalidity}/{uid}{getmail_retrieval_timestamp}
Messages might be stored into disk ("/var/lib/nethserver/vmail/user@domain.tld/Maildir/*/") with a slightly different timestamp, naming them according to (dovecotās) maildir format:
You switched the server+protocol used for the accountās e-mail retrieval, in the POP3 Connector, from IMAP to POP3.
After getmail contacted the POP3 server to retrieve the list of e-mail messages, it created a new oldmail index list file, therefore no message was logged as seen, the first time. Also note the getmail msgid format stored in oldmail* files differs between protocols.
When switching back to IMAP, getmail either reused an existing oldmail* file or created a new one (depending on the parameters set for server name, port, account, mailboxā¦)
ll /var/lib/getmail/oldmail*
Note this information is mostly guessed (accuracy of given information and terminology can be questioned, does not come from an official source).
Message retrieved, stored into Junk, deleted from main server:
Aug 24 12:40:13 lrtserv-data dovecot: lda(user@mydomain.lan): sieve: msgid=<-------------------------------@----------.--->: stored mail into mailbox 'Junk'
Aug 24 12:40:13 lrtserv-data getmail: msg 2/4 (7388 bytes) msgid 1092066676/182724 from ----------@---------.--- delivered to MDA_external command dovecot-lda (), deleted
I could be wrong but what follows seems to be a different message with duplicate UID: the first one, with same UID, was deleted from the main server (so couldnāt be there); both messages have different size.
getmail finds the msgid listed in its oldmail index, considers it was retrieved in the past, deletes it from main server:
Aug 28 21:35:01 lrtserv-data getmail: msg 1/1 (7781 bytes) msgid 1092066676/182724 not retrieved (seen), deleted
Thatās what it looked like to me as well, but how could that happen?
Does that meant there is not issue to worry about with NS, and the fault was at my host end, and I should persue the error there? NS seems to be working well now retrieving the email for the user.
afaik, the message uid should remain unique within an IMAP mailbox. Donāt know what happened (if messages were nowhere to be found on the inbox, junkā¦ or under /var/lib/nethserver/vmail/*).
We could have missed something else, but with the only information we have Iād investigate your host end (main mail server).