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>
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>
