In imaplib, cached capabilities may be out of date after login

@vstinner

BPO	18921
Nosy	@vstinner, @mcepl, @bitdancer

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2013-09-04.14:27:30.821>
labels = ['type-feature', 'library']
title = 'In imaplib, cached capabilities may be out of date after login'
updated_at = <Date 2018-07-19.11:59:03.110>
user = 'https://bugs.python.org/sjmurdoch'

bugs.python.org fields:

activity = <Date 2018-07-19.11:59:03.110>
actor = 'vstinner'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2013-09-04.14:27:30.821>
creator = 'sjmurdoch'
dependencies = []
files = []
hgrepos = []
issue_num = 18921
keywords = []
message_count = 4.0
messages = ['196920', '196925', '315573', '321954']
nosy_count = 4.0
nosy_names = ['vstinner', 'mcepl', 'r.david.murray', 'sjmurdoch']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue18921'
versions = ['Python 3.5']

Linked PRs

When an IMAP server is behind a proxy, the proxy's capabilities may differ from that of the actual IMAP server. However, in Python imaplib, the client will ignore any updates to available capabilities in the response to the LOGIN command (see rfc3501, section 6.2.3). As a result, imaplib will incorrectly assume that certain features are not available (including the IDLE patch in bpo-11245, and as implemented in getmail 4.43.0). imaplib should refresh its capability list either based on the result of the login command or by explicitly sending a CAPABILITY command following login.

I agree that this would be a good idea, but it is not a bug in the current implementation. The only place imaplib itself uses the cached capabilities is *before* login, in the starttls method, and there it refreshes it after starttls succeeds.

Although it isn't documented any more than the 'capabilities' attribute is (and therefor neither are part of the public API currently), you can call the capability command yourself if you need the refreshed capabilities in your own code.

Good catch on the bug in the IDLE patch, though.

Well, and would it be too much to refresh capabilities attribute in the end of login method?

See also bpo-33327: Add a method to move messages to IMAPlib.

The inconsistency is a problem for the ENABLE capability support that was added in #65999; see #103451.

The capabilities attribute was already mentioned in the authenticate documentation as a collection (https://docs.python.org/3/library/imaplib.html#imaplib.IMAP4.authenticate):

mechanism . . . should appear in the instance variable capabilities

gh-63121: Refresh imaplib capabilities on state changes (GH-152752)

[3.14] gh-63121: Refresh imaplib capabilities on state changes (GH-15…

[3.15] gh-63121: Refresh imaplib capabilities on state changes (GH-15…

Fixed in #152752: imaplib now refreshes the cached capabilities after login and other state changes.

[3.13] gh-63121: Refresh imaplib capabilities on state changes (GH-15…

Navigation Menu

Repository navigation

In imaplib, cached capabilities may be out of date after login #63121

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

In imaplib, cached capabilities may be out of date after login #63121

Description

Linked PRs

Activity

sjmurdoch commented on Sep 4, 2013

bitdancer commented on Sep 4, 2013

mcepl commented on Apr 21, 2018

vstinner commented on Jul 19, 2018

vadmium commented on Apr 14, 2024

serhiy-storchaka commented on Jul 2, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions