The new 'utf8foldernames' will not work together with the existing
'decodefoldernames' option (which will be documented in the next
commit). Therefore this commit will check for this condition and
abort the synchronization of a misconfigured account before doing
any changes.
Other accounts are not affected.
Signed-off-by: Urs Liska <git@ursliska.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
If utf8foldernames is enabled on account level all folder names read
from the IMAP server will immediately be reencoded to UTF-8. Names
will be treated as UTF-8 as long as the IMAP server isn't contacted again,
for which they are reencoded to IMAP4-UTF-7.
This means that any further processing such as nametrans, folderfilter
etc. will act upon the UTF-8 names, which will have to be documented
carefully.
NOTE 1:
GMail repositories and folders inherit from the IMAP... classes, so I don't
know yet if these changes have ugly side-effects. But web research suggests
that GMail IMAP folders are equally encoded in UTF-7 so that should work
identically here and incorporate the same improvements.
NOTE 2:
I could not test the behaviour with idlefolders as I didn't get this option
to work at all, not even with the latest stable version.
NOTE 3:
I *did* test to sync an IMAP repository against another IMAP repository.
Signed-off-by: Urs Liska <git@ursliska.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
While intending *not* to change the behaviour of the existing
decodefoldernames option this commit transparently improves
the coding.
So far this worked by overriding the folder's getvisiblename() method
which reads self.visiblename from and applies the conversion on
*every* invocation of getvisiblename().
This commit does the calculation once in the IMAPFolder's __init__.
Signed-off-by: Urs Liska <git@ursliska.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
This commit adds two functions
- imaputil.IMAP_utf8()
- imaputil.utf8_IMAP()
as an interface to the new imap4_utf_7 codec.
Signed-off-by: Urs Liska <git@ursliska.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
If the config option `transporttunnel` is used the option `remotehost` is not
needed, because the tunnel provide the IMAP connection.
Signed-off-by: Thomas Merkel <tm@core.io>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
The support for the realdelete configuration option was removed because this
could lead to data loss.
See 51728ed to know more.
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Fixed typo in the default config file, the word "negociation" is changed to
"negotiation" as the original author intended.
Originally-sent-by: Alvaro Pereyra <alvaronh@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Some returned responses end with ')' rather than 'UID XXX)' as expected.
BTW, a better policy could be to request for the 'X-OfflineIMAP' header only
rather than fetching all the headers and looking for it manually.
Also:
- Strip the output when error occurs: we don't need the full response unless
'imap' debug mode is enabled.
- Improve the comments.
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/479
Tested-by: https://github.com/secomi
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
- rewrite the release script from shell to python3
- refactoring of the upcoming script and introducing the helpers library
- introduce the tested-by.py script to manage the feedbacks from the testers
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
systemd conventions specify that timers trigger services with the same
name (this can be overridden, of course).
We're currently providing:
* offlineimap-oneshot.service
* offlineimap.service
* offlineimap.timer
This is rather confusing, since the timer doesn't actually provide the
service of the same name (even though they're bundled together!!), but a
different one.
Signed-off-by: Hugo Osvaldo Barrera <hugo@barrera.io>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Providing mail.target is really confusing and poor UX:
* When a user enables a unit, it's not truly enabled until they ALSO
enable mail.target. This is very counter-intuitive.
* `mail.target` provides no extra value in itself, nor is it anything
"standard".
* Any user wanting this specific target can still continue using it just
dropping in a `mail.target` file.
Signed-off-by: Hugo Osvaldo Barrera <hugo@barrera.io>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
oneshot units CANNOT have a `Restart=` setting, and including one
invalidates the service file.
Signed-off-by: Hugo Osvaldo Barrera <hugo@barrera.io>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
No need to overcomplicate things; systemd grabs all stdout output and
logs that.
Signed-off-by: Hugo Osvaldo Barrera <hugo@barrera.io>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Add restart on failure and increase timeout to kill service.
Signed-off-by: benutzer193 <registerbn@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Be more obvious that the legacy plain text cache is not supported while we still
support the migration to the sqlite format.
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
On each folder scan, we must compute the min_uid. Locally, this is done by
relying on the prefix timestamp in the filenames. If for whatever reason they do
not reflect the Date header of the email, changing maxage leads to undefined
behaviour.
To prevent from this, we rather rely on the remote folder. We assume that the
remotes are more reliable to provide correct sets of UIDs based on dates than we
are.
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/384
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
mbnames is initialized and written once in the run from OfflineImap.__sync().
However, the in-memory instance is fed with data at sync time for each folder
and the intermediate files are written as soon as all the folders are synced for
the account. All of this is done inside the SyncableAccount.__sync() method
while the syncrunner is looping on this.
This means that we duplicate entries for mbnames in each loop (most likely when
autorefresh is enabled).
It is wrong to have duplicates in mbnames for each account. Ignore duplicates
when adding data in the mbnames intermediate files.
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/467
Reported-and-tested-by: Shin Kojima <shin@kojima.org>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>