Fetchmail to keep original date/time

Question

I'm setting up my own IMAP and I need to gather emails received during the last 9 years in my own server (and to continuously synchronize from a few email boxes).

I have successfully set up fetchmail with a test account on an empty mailbox. Whenever I send mail to the target mailbox, it will be picked up via POP3 into my box. But I discovered that the message I'm delivered into Windows Mail shows the date/time when fetchmail ran. This can be appropriate for new mail, but really inappropriate for history tracking.

My .fetchmailrc file currently * shows

set invisible

poll pop.fastwebnet.it proto imap
        user "redacted" pass "redacted" fetchall
        mda "/usr/lib/dovecot/deliver"

My inbox is configured using Postfix & Dovecot with Maildir format. I chose POP3 for fetchmail because it will delete the message once synchronized to maildir.

How can I tell fetchmail that new mail dropped into Maildir must match exactly what found on server, with reference to date and time?

I mean, if I went to synchronize my history from [e-mail] that accumulated 9 years of mail, all of them will be dated today!

For example, I sent myself a test email at about 14:59 to [e-mail], opened the webmail at fastwebnet.it to confirm that 14:59 was the "official" time, then ran fetchmail from my server at 15:30. Windows Mail showed that the email's time was 15:30 instead of 14:59.

Updates

From the comment and by reading the documentation, it looks clear that fetchmail normally adds a Received header at the top of the email so the client will detect the mail is brand new.

I also ran fetchmail in verbose mode, this time using IMAP. It seems that by default it drops mail via SMTP, so that's where the problem lies. If my server receives a mail via SMTP to be dropped into Maildir, it will assume that the email is brand new.

*I have updated my questions from the original writing

Answer 1

It appears that the date exposed to the user by Windows Mail does not come from the Date header field, but rather from the latest Received field (Received fields are primarily meant to trace a message through delivery gateways, as mentioned in RFC5321 and RFC5322).

When fetchmail delivers a message, even with the mda option (not using SMTP), by default it adds its own Received field with the current date and time.

Fortunately it provides an option to disable this:

The --invisible option (keyword: set invisible) tries to make fetchmail invisible. Normally, fetchmail behaves like any other MTA would -- it generates a Received header into each message describing its place in the chain of transmission, and tells the MTA it forwards to that the mail came from the machine fetchmail itself is running on. If the invisible option is on, the Received header is suppressed and fetchmail tries to spoof the MTA it forwards to into thinking it came directly from the mailserver host.

I believe you want to combine this option with a non-SMTP delivery, for instance with --mda /usr/lib/dovecot/deliver. Otherwise the SMTP server would probably add its own Received field after fetchmail.

Answer 2

Since the scope of the question was to perform an "initial" hystorical migration of mailbox, here are different brute force approaches: move emails from old IMAP to new inbox. From then on, fetchmail daemon will work fine with new mail

Via client (e.g. Outlook)

Synchronize both mailboxes, select all (or groups of) emails and drag&drop or cut&paste them into the new Inbox. This will take some time and manual work, but can do none or little damage, especially if you move emails in groups

Via dump

Since I have access to the server, a tool such as imap2maildir can dump an IMAP box into a Maildir compatible box. Merging the original Maildir with the new one initializes message collection correctly

Via any other specific commercial tool

There are plenties of tools made for IMAP migration/synchronization. There are even online tools, to which you must provide your box password (for your security you may change the password to a temporary one during migration), and you must trust the service not to keep your personal data.