On some architectures, using threading.TIMEOUT_MAX for the timeout
parameter can overflow causing Condition.wait() to return immediately.
Instead of relying on TIMEOUT_MAX, remove it and wait forever.
Signed-off-by: Ilias Tsitsimpis <iliastsi@debian.org>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
While trying to see why I couldn't get my emails from an Exchange server
I found this:
[imap]: 41:31.42 someserver.com handler _put_response(IOMC1 OK)
[imap]: 41:31.42 someserver.com handler unexpected response: 'IOMC1 OK'
And shortly after that the connection was closed. IOMC1 is just the
unique tag for the session.
The pattern looks for the tag, a number, a word like "OK" or something,
*then a space*, then optionally some data.
If the data aren't there it shouldn't be expecting a space.
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
This allows OfflineIMAP to not stall on malfunctional IPv6 connections,
and fall-back to a functional IPv4 connection, if faster, as described
in RFC6555.
Signed-off-by: Olivier Mehani <shtrom@ssji.net>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
When creating a folder in one command on Gmail you end up with
one tag such as 'x/y/z' instead of three nested tags such as 'z'
inside of 'y' inside of 'x'. Creating each layer individually
results in the desired nested label structure.
This was tested in a personal transfer of email from a remote
IMAP server to Gmail.
OfflineIMAP/offlineimap#335OfflineIMAP/offlineimap#598
Signed-off-by: Kyle Altendorf <sda@fstab.net>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
addch() and addstr() throw an exception if text has to be printed
outside of the window. This may occur if the terminal is very small.
Such erroneous prints are no-ops now.
Signed-off-by: Mart Lubbers <mart@martlubbers.net>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/595
This fixes a potential traceback when we try to unwrap(None).
Tested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Use `expires_in` from the oauth2 response
to reset the oauth2_access_token before
it expires
divides the `expires_in` by 2 to ensure
the access_token is cleared before it
expires
ref: https://github.com/OfflineIMAP/offlineimap/issues/536
Signed-off-by: Frode Aannevik <frode.aa@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
There is a bug with `platform.linux_distribution()`, which returns an
empty value on Archlinux with python2.
This bug is fixed in python3, but *will not* be fixed in python2.
This patch fixes that issue with a dirty hack: on archlinux, there is a
file that can be used to detect an archlinux machine. that file is
`/etc/arch-release`. if the file exists, then the OS variable will be
set to "linux-arch".
You can learn more about that issue on the python bug platform:
https://bugs.python.org/issue20454
Signed-off-by: Philippe Loctaux <loctauxphilippe@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
A certfile was already specified for osx but only with MacPorts,
this patch adds the certfile given with the package `openssl` with
homebrew.
You can get more info with the command `brew info openssl` on osx with
homebrew and openssl installed.
Signed-off-by: Philippe Loctaux <loctauxphilippe@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
get_os_name returns linux-arch on Archlinux, so add a line for linux-arch to __DEF_OS_LOCATIONS.
Signed-off-by: Philippe Loctaux <loctauxphilippe@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
If the tls_level is set to a cipherset other than tls_compat, the
ssl cipherset has to get specified extra, if ssl is used.
But if the user explicitly disabled SSL, and set tls_level to anything
else than tls_compat required the user to explicitly set ssl_version,
which is contradicting.
Signed-off-by: Benedikt Heine <bebe@bebehei.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
