Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

imaplib.py MAXLINE value is too low for gmail #67835

Closed
arnt mannequin opened this issue Mar 12, 2015 · 9 comments
Closed

imaplib.py MAXLINE value is too low for gmail #67835

arnt mannequin opened this issue Mar 12, 2015 · 9 comments
Labels
stdlib Python modules in the Lib dir topic-email type-feature A feature request or enhancement

Comments

@arnt
Copy link
Mannequin

arnt mannequin commented Mar 12, 2015

BPO 23647
Nosy @warsaw, @bitdancer
Files
  • 0001-Increase-IMAP-line-length-limit.patch: Patch to solve.
    		•

    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 = <Date 2022-03-19.20:12:11.923>
created_at = <Date 2015-03-12.15:39:25.057>
labels = ['type-feature', 'library', 'expert-email']
title = 'imaplib.py MAXLINE value is too low for gmail'
updated_at = <Date 2022-03-19.20:12:11.923>
user = 'https://bugs.python.org/arnt'

    bugs.python.org fields:

    activity = <Date 2022-03-19.20:12:11.923>
actor = 'iritkatriel'
assignee = 'none'
closed = True
closed_date = <Date 2022-03-19.20:12:11.923>
closer = 'iritkatriel'
components = ['Library (Lib)', 'email']
creation = <Date 2015-03-12.15:39:25.057>
creator = 'arnt'
dependencies = []
files = ['38456']
hgrepos = []
issue_num = 23647
keywords = []
message_count = 9.0
messages = ['237950', '237967', '237985', '237988', '238933', '238937', '238990', '239123', '239128']
nosy_count = 4.0
nosy_names = ['barry', 'r.david.murray', 'python-dev', 'arnt']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue23647'
versions = ['Python 3.5']
    @arnt
    Copy link
    Mannequin Author

    arnt mannequin commented Mar 12, 2015

    http://stackoverflow.com/q/28923997 and various other SO questions point out that imaplib's _MAXLINE value is a bit behind the times. Fine for 1997, when people had 10MB mailbox quotas, not so fine for the age of gmail.

    I'm tired of seeing those questions, so the attached patch increases the limit without abolishing it completely.

    There are also other issues in imaplib, but I fix just this one now, to test the waters so to speak.

    FWIW, I've signed the contributor form, just in case.

    @arnt arnt mannequin added stdlib Python modules in the Lib dir type-feature A feature request or enhancement labels Mar 12, 2015
    @bitdancer
    Copy link
    Member

    Gmail breaks the standards again, eh? I suppose we'll have to accommodate them ;)

    @bitdancer bitdancer changed the title imaplib.py MAXLINE value is too low for 2015 (patch attached) imaplib.py MAXLINE value is too low for gmail Mar 12, 2015
    @arnt
    Copy link
    Mannequin Author

    arnt mannequin commented Mar 12, 2015

    The RFC in question is 2683, which isn't a standard, it's just advice.

    What gmail breaks is the expectation that mailboxes and seach results are smallish. If you run a python script on gmail and it runs a search, the result can be a great deal bigger than the author of RFC2683 foresaw.

    @bitdancer
    Copy link
    Member

    Sorry, I was being a facetious, but despite the smiley that wasn't clear. I *have* run into a number of cases where gmail violates the standard, but I wasn't really serious about this case.

    @bitdancer
    Copy link
    Member

    Now that I've had time to look at this, I see that in fact RFC2683 says nothing about what value MAXLINE should have, unless one is reasoning by analogy. It is concerned with *command line* lengths from the client to the server, not about server responses. It seems as though we really should be handling more or less arbitrary length lines in the server response.

    I'll bump up the limit in the meantime.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Mar 22, 2015

    New changeset a56aa567072c by R David Murray in branch '2.7':
    bpo-23647: Increase imaplib's MAXLINE to accommodate modern mailbox sizes.
    https://hg.python.org/cpython/rev/a56aa567072c

    New changeset c1348ada8fc6 by R David Murray in branch '3.4':
    bpo-23647: Increase imaplib's MAXLINE to accommodate modern mailbox sizes.
    https://hg.python.org/cpython/rev/c1348ada8fc6

    New changeset be6c4569f845 by R David Murray in branch 'default':
    Merge: bpo-23647: Increase imaplib's MAXLINE to accommodate modern mailbox sizes.
    https://hg.python.org/cpython/rev/be6c4569f845

    @arnt
    Copy link
    Mannequin Author

    arnt mannequin commented Mar 23, 2015

    You're entirely right. I should've reread 2683 too (a decade has passed since I read that).

    The danger with accepting the unlimited line length is that batch scripts might accept an infinitely large batch. Which is a matter of python culture, really.

    (This has been a very positive experience.)

    @bitdancer
    Copy link
    Member

    Yes, I agree that that is a concern. What should probably happen is that the maximum line length be a settable parameter with a "reasonable" default. It is too bad that (unlike say the SMTP protocol) the imap protocol does not address this directly.

    @arnt
    Copy link
    Mannequin Author

    arnt mannequin commented Mar 24, 2015

    Length limits has actually been discussed and rejected; noone had a proposal that solved more problems than it introduced.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    stdlib Python modules in the Lib dir topic-email type-feature A feature request or enhancement
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    2 participants
    @bitdancer @iritkatriel