We use current hostname as the element of the unique file name.
Sometimes there is non-/24 zone delegation,
{{{
$ host 144.206.233.65
65.233.206.144.in-addr.arpa is an alias for 65.26/64.233.206.144.in-addr.arpa.
}}}
as per RFC 2317,
https://www.rfc-editor.org/rfc/rfc2317.txt
So on Un*x systems we may run into having path separator inside
the file name. Not good, things will choke. Prevented this
by substituting all appeared path separators in the return value.
Signed-off-by: Eygene Ryabinkin <rea@codelabs.ru>
Tested-at: my MacOSX instance, my FreeBSD instances
python-gssapi has a visible, active upstream and a more pleasant
interface. python-gssapi is present in most distributions, while
pykerberos is slated for removal from Fedora/RHEL/CentOS.
Github-ref: https://github.com/OfflineIMAP/offlineimap/pull/529
Tested-by: Robbie Harwood <rharwood@redhat.com>
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
With new emails we could have negative UIDs in come use cases. Exclude these
from the list of UIDs. The negative UIDs lead to invalid SEARCH command:
SEARCH command error: BAD ['Could not parse command']. Data: FMAO19 SEARCH (UID -4:*)
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/512
Tested-by: https://github.com/shubhamkrm
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
It was previously printing "Upgrading LocalStatus cache from version 1to version 2 for XXX"
Signed-off-by: John Ferlito <johnf@inodes.org>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
When there is not UIDPLUS we have to figure the UID by our means. When this
process fails, we don't know if the email was successfully uploaded. This patch
provides better logs to explain what happened.
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
It's required to modify my change 1ce596d713
because a hostname shouldn't be needed if any tunnel is used. Both tunnels
provide a regular IMAP interface which is used by offlineimap.
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/503
Reported-by: Ilias Tsitsimpis <i.tsitsimpis@gmail.com>
Signed-off-by: Thomas Merkel <tm@core.io>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
This behaviour is what users would expected most. The error message is about
utf8foldernames and decodefoldernames.
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
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>
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>
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>
Some users might use more than one python/imaplib version. This tends to make
debugging and support harder.
Displaying this information by default for each run should help.
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Checking if we have to run this authentication method once it's already passed
to imaplib2 is too late. Make the checks at correct time, before we try the
authentication method. IOW, before we call
imapobj.authenticate('XOAUTH2', self.__xoauth2handler)
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/442
Tested-by: Klemens Schölhorn <klemens@schoelhorn.eu>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Make sure that we refresh the screen atomically, since the emit()
function may be called by more that one threads at a time.
Also, modify the draw_bannerwin() method which used to fail in case the
window would become too small. Make sure that the provided offsets to
the window.addstr() method are properly bounded.
Closes#160: blinkenlights display is broken
Tested-by: Cyril Brulebois
Tested-by: Gaudenz Steinlin
Signed-off-by: Ilias Tsitsimpis <i.tsitsimpis@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
