offlineIMAP/docs/offlineimap.known_issues.txt

* Deletions.
+
While in usual run the deletions are propagated. To prevent from data loss,
removing a folder makes offlineimap re-sync the folder. However, propagating the
removal of the whole content of a folder can happen in the two following cases:

  - The whole content of a folder is deleted but the folder directory still
    exists.

  - The parent directory of the folder was deleted.

* SSL3 write pending.
+
Users enabling SSL may hit a bug about "SSL3 write pending". If so, the
account(s) will stay unsynchronised from the time the bug appeared. Running
OfflineIMAP again can help. We are still working on this bug.  Patches or
detailed bug reports would be appreciated. Please check you're running the
last stable version and send us a report to the mailing list including the
full log.

* IDLE support is incomplete and experimental. Bugs may be encountered.

  - No hook exists for "run after an IDLE response".
+
Email will show up, but may not be processed until the next refresh cycle.

  - nametrans may not be supported correctly.

  - IMAP IDLE <-> IMAP IDLE doesn't work yet.

  - IDLE might stop syncing on a system suspend/resume.

  - IDLE may only work "once" per refresh.
+
If you encounter this bug, please send a report to the list!

* Maildir support in Windows drive.
+
Maildir uses colon character (:) in message file names. Colon is however
forbidden character in windows drives. There are several workarounds for that
situation:

    . Enable file name character translation in windows registry (not tested).
      - <http://support.microsoft.com/kb/289627>

    . Use cygwin managed mount (not tested).
      - not available anymore since cygwin 1.7

    . Use "maildir-windows-compatible = yes" account OfflineIMAP configuration.
      - That makes OfflineIMAP to use exclamation mark (!) instead of colon for
        storing messages. Such files can be written to windows partitions. But
        you will probably loose compatibility with other programs trying to
        read the same Maildir.
+
      - Exclamation mark was chosen because of the note in
        http://docs.python.org/library/mailbox.html
+
      - If you have some messages already stored without this option, you will
        have to re-sync them again

* OfflineIMAP confused after system suspend.
+
When resuming a suspended session, OfflineIMAP does not cleanly handles the
broken socket(s) if socktimeout option is not set.
You should enable this option with a value like 10.

* OfflineIMAP confused when mails change while in a sync.
+
When OfflineIMAP is syncing, some events happening since the invocation on
remote or local side are badly handled. OfflineIMAP won't track for changes
during the sync.


* Sharing a maildir with multiple IMAP servers.
+
Generally a word of caution mixing IMAP repositories on the same Maildir root.
You have to be careful that you *never* use the same maildir folder for 2 IMAP
servers. In the best case, the folder MD5 will be different, and you will get
a loop where it will upload your mails to both servers in turn (infinitely!)
as it thinks you have placed new mails in the local Maildir. In the worst
case, the MD5 is the same (likely) and mail UIDs overlap (likely too!) and it
will fail to sync some mails as it thinks they are already existent.
+
I would create a new local Maildir Repository for the Personal Gmail and
use a different root to be on the safe side here. You could e.g. use

    `~/mail/Pro' as Maildir root for the ProGmail and
    `~/mail/Personal' as root for the personal one.
+
If you then point your local mutt, or whatever MUA you use to `~/mail/'
as root, it should still recognize all folders.


* Edge cases with maxage causing too many messages to be synced.
+
All messages from at most maxage days ago (+/- a few hours, depending on
timezones) are synced, but there are cases in which older messages can also be
synced. This happens when a message's UID is significantly higher than those of
other messages with similar dates, e.g. when messages are added to the local
folder behind offlineimap's back, causing them to get assigned a new UID, or
when offlineimap first syncs a pre-existing Maildir. In the latter case, it
could appear as if a noticeable and random subset of old messages are synced.

* Passwords in netrc.
+
Offlineimap doesn't know how to retrieve passwords when more than one account is
stored in the netrc file. See
<https://github.com/OfflineIMAP/offlineimap/issues/295>.

* XOAUTH2
+
XOAUTH2 might be a bit tricky to set up. Make sure you've followed the step to
step guide in 'offlineimap.conf'. The known bugs about Gmail are tracked at
<https://github.com/OfflineIMAP/offlineimap/labels/Gmail>.
+
Sometimes, you might hit one of the following error:

- [imap]: xoauth2handler: response "{u'error': u'invalid_grant'}"
- oauth2handler got: {u'error': u'invalid_grant'}

+
In such case, we had report that generating a new refesh token from the same
client ID and secret can help.
+
.Google documentation on "invalid_grant"
----
When you try to use a refresh token, the following returns you an
invalid_grant error:

  - Your server's clock is not in sync with network time protocol - NTP.
  - The refresh token limit has been exceeded.
----
+
.Token expiration
----
It is possible that a granted token might no longer work. A token might stop
working for one of these reasons:

  - The user has revoked access.
  - The token has not been used for six months.
  - The user changed passwords and the token contains Gmail scopes.
  - The user account has exceeded a certain number of token requests.

There is currently a limit of 50 refresh tokens per user account per client. If
the limit is reached, creating a new token automatically invalidates the oldest
token without warning. This limit does not apply to service accounts.
----
+
See <https://developers.google.com/analytics/devguides/config/mgmt/v3/authorization>
and <https://developers.google.com/identity/protocols/OAuth2#expiration>
to know more.