POP3 Connector emails disappearing

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.

2 Likes

I see messages like that for the other user, I wish they were more detailed so I could see who they are delivered to.
I see a bunch of these;

**Aug 28 21:35:01 lrtserv-data getmail: msg 1/1 (7781 bytes) msgid 1092066676/182724 not retrieved (seen), deleted

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.

Just another idea, change from pop to imap or vice versaā€¦

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.

Glad to read this.

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.

1 Like

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ā€¦

Hope that one of the points will help youā€¦

1 Like

TL;DR

  • message seen (retrieved) in the past
  • 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:

{delivery_timestamp}.M264711P4655.{hostname},S={size},W={virtual_size}:2,{flags}


  1. You switched the server+protocol used for the accountā€™s e-mail retrieval, in the POP3 Connector, from IMAP to POP3.
  2. 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.
  3. 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).

2 Likes

Not sure if this helps, but this is the output of the above command;

/var/log/maillog-20170827-Aug 24 12:40:13 lrtserv-data dovecot: lda(user@mydomain.lan): sieve: msgid=<4619713749167410646197219419991025955399@wcq2nfr
a.lotlocked.stream>: stored mail into mailbox ā€˜Junkā€™
/var/log/maillog-20170827:Aug 24 12:40:13 lrtserv-data getmail: msg 2/4 (7388 bytes) msgid 1092066676/182724 from worldwoman@lotlocked.stream delivered to M
DA_external command dovecot-lda (), deleted

/var/log/maillog-20170904-Aug 28 21:30:04 lrtserv-data getmail: msg 1/1 (7284 bytes) msgid sm_0007C063_49b0fda5edc84dec93518ea5ddd04952 from <lilly.l@dljhc.bi
d> delivered to MDA_external command dovecot-lda (), deleted
/var/log/maillog-20170904:Aug 28 21:35:01 lrtserv-data getmail: msg 1/1 (7781 bytes) msgid 1092066676/182724 not retrieved (seen), deleted

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
1 Like

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