- 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
Messages might be stored into disk (
"/firstname.lastname@example.org/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…)
Note this information is mostly guessed (accuracy of given information and terminology can be questioned, does not come from an official source).