This patch only adds an space between the hash and the first character.
Backported from:
a88a9cf28e
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
`presynchook` and `postsynchook` for IDLE-triggered syncs were broken by
da69fd8. This fixes them.
Signed-off-by: Reto Schnyder <reto.a.schnyder@bluewin.ch>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
When the IMAP server doesn't support the UIDPLUS extension so we fallback on the
internal legacy way of mapping the UID to the uploaded message (with the email
header). If the server responds with 2 UIDs offlineimap doesn't know which one
is correct and reports an error.
If for some reason all the returned UIDs are equals it's very likely fine to
map either one.
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Tested-by: https://github.com/mpsq
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/676
The setup.py uses the version, author and others attributes as metadata
for the python package.
The setup read them from offlineimap/__init__.py doing an import of the
module first.
Unfortunately the import also try to import all the dependencies of
offlineimap which may not be installed by the time. See #661.
Moving out the attributes in a separated module allows to be imported by
setup.py whitout needing to import the whole offlineimap.
The import of test.OLItest has the same limitation. In this case the
import was delayed until the real test case run is executed avoiding
again loading offlineimap from the begin.
Signed-off-by: Martin Di Paola <martinp.dipaola@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Inside __authn_gssapi function, the else clause is never executed
because the return statement in the try section, which means if there is
an error and a reconnect is tried, the authentication will now fail with
due the stale self.gss_vc value. For example, offlineimap will be
stuck after any socket error and unable to reconnect, even if I have a
valid kerberos ticket:
========================================================================
abort: command: FETCH => socket error: <type 'exceptions.IOError'> - Too many read 0
command: FETCH => socket error: <type 'exceptions.IOError'> - Too many read 0
GSSAPI authentication failed: AUTHENTICATE command error: BAD ['AUTHENTICATE aborted']. Data: BLMC2 AUTHENTICATE GSSAPI
Enter password for user 'XXX':
========================================================================
You can verify this try..finally behaviour with this slightly modified
example that I copied from python documentation:
>>> def divide(x, y):
... try:
... result = x / y
... return 1
... except ZeroDivisionError:
... print("division by zero!")
... else:
... print("result is", result)
... finally:
... print("executing finally clause")
...
>>> divide(2, 1)
executing finally clause
1
>>>
The else section is never executed with a return inside try.
To fix the issue here, instead of relying on else clause, just clear
gss_vc always inside finally, and we don't need to handle any exception
to set self.gssapi, it can be left False by default and just set to True
after authentication is done.
I'm running with this fix and now offlineimap doesn't stop requiring manual
intervention, and succesfully re-authenticate after errors while fetching
data.
Signed-off-by: Herton R. Krzesinski <herton@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
This commit allows account hooks (pre/post sync) to access contextual
information:
* `OIMAP_ACCOUNT_NAME`: name of the account being synchronized
* `OIMAP_HOOK_NAME`: name of the hook being run (one of `postsynchook`, `presynchook`)
These variables allow using the same hook program (e.g. a script) for
all account synchronisation operations, and running different commands
depending on the stage of the synchronisation or the target account.
Signed-off-by: Frank LENORMAND <lenormf@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
There is no reason that the shell invoking the tunnel command needs to stay
around. Using `exec` to replace the parent with the tunnel command works just
fine and results in a cleaner process table.
Sent-by: martin f. krafft <madduck@madduck.net>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Make compatible with IMAP servers that give the reason code "[ALREADYEXISTS]"
and IMAP servers that give natural language reason "Mailbox already exists!" by
searching for the two words "already" and "exists" in the exception reason
string.
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
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>
If the username value is not provided on the configuration file, then
username if of NoneType and NULL.join will bomb since Nones can't be
joined with strings. So check if username is empty and raise an
exception if so.
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/558
Signed-off-by: David Miguel Susano Pinto <carandraug+dev@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
When asking for a password interactively, the username is never
displayed which may hide problems (typos on the configuration, or
issues on offlineimap parsing of the config file). The hostname,
port, and account name are already displayed when establishing the
connection. When asking for password, the account name is displayed
again. Change it to display the username.
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/558
Signed-off-by: David Miguel Susano Pinto <carandraug+dev@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Fix bug in GSSAPI auth where the username was not being negotiated.
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/541
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Tested-by: Frank Lenormand <lenormf@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Reported-by Heinrich Hartmann <Heinrich@HeinrichHartmann.com>
Tested-by Heinrich Hartmann <Heinrich@HeinrichHartmann.com>
Github-ref: https://github.com/OfflineIMAP/offlineimap/issues/545
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>