IMAP <> IMAP sync introduces a large fixed offset for the received date-time when mail headers contain a negative timezone (eg a USA-based remote mail host).

[peterb-dev]

General informations

• system/distribution (with version): Debian 12.5 (docker python:3 base image)
• offlineimap version: v8.0.0 ( and imaplib2 v3.06 ), SHA d29a4dc
• Python version: 3.12.2
• server name or domain: any IMAP server using a negative timezone (eg USA)
• CLI options: None

Configuration file offlineimaprc

NOTE: This is a two-way IMAP config (remote IMAP <> local IMAP)

[general]
pythonfile = ./config_helpers_fastmail.py
metadata = <path-to-metadata>
accounts = fastmail-account

[Account fastmail-account]
localrepository = local-imap
remoterepository = remote-fastmail
autorefresh = 10
quick = 11

[Repository remote-fastmail]
type               = IMAP
remotehost         = mail.messagingengine.com
remoteport         = 993
ssl                = yes
holdconnectionopen = yes
remoteuser         = <secret>
remotepass         = <secret>
sslcacertfile      = /etc/ssl/certs/ca-certificates.crt
folderfilter       = folderfilter_remote_fastmail
nametrans          = nametrans_remote_fastmail_to_local_imap
idlefolders        = ['INBOX']

[Repository local-imap]
type               = IMAP
remotehost         = <secret>
remoteport         = 993
ssl                = yes
holdconnectionopen = yes
remoteuser         = <secret>
remotepass         = <secret>
sslcacertfile      = /etc/ssl/certs/ca-certificates.crt
folderfilter       = folderfilter_local_imap_fastmail
nametrans          = nametrans_local_imap_fastmail
idlefolders        = ['INBOX']

Logs, error

doveadm dump -t index <path-to-maildir>/dovecot.index <uid>
Relevant fields from metadata include:
    - hdr.DATE: 194: Date: Mon, 01 May 2023 19:12:53 +0100
    - date.received: 1682935996 (bc904f64)  => Monday, May 1, 2023 10:13:16 AM (GMT)

Steps to reproduce the error

• Configure an IMAP<>IMAP sync, and observe the received time of the items in your inbox, versus those on the original server.
• The server must operate in a negative timezone (check the message headers to confirm this).
• Perhaps also visible in a maildir <> IMAP sync at some level, though I have not noticed it before when using a maildir backend.

Comments

My local (dovecot) IMAP server shows a date-time received about 8 hours prior to email header date-time (which defies causality...). When an IMAP client views mail items in a folder view (roundcube, fairEmail, etc), this erroneous date.received time is displayed. Opening the item typically displays both 'sent' date (from email headers, which is correct), and 'received' date (from IMAPv4 headers, which is wrong).
Note, the hdr.DATE in the above 'doveadm dump' has a positive TZ (timezone of the sender), but the intermediate mail-header hops contain a 14:13:16 -0400 (EST) timezone, which is the cause of this problem (I know this as I've fixed and verified the root cause in a pull request).
I believe offlineimap3 must parse one of these mail headers as 14:13:16 +0400 (ie: +, not -), to arrive at 10:13:16 GMT when setting INTERNALDATE attribute towards my local IMAP server.

[peterb-dev]

Interesting to note that offlineimap3 requires imaplib2, which implements the bug-free variant as Internaldate2Time(), though I can see this does not return an Unix epoch as IMAPv4 requires. We could probably migrate to use Internaldate2Time() and convert the returned 'localtime' object back to a Unix epoch for INTERNALDATE use, but that fix is more than one character :-)

[eyeinsky]

Is this issue now resolved?