➜
This issue trackerhas been migrated toGitHub, and is currentlyread-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.
Created on2015-03-12 15:39 byarnt, last changed2022-04-11 14:58 byadmin. This issue is nowclosed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| 0001-Increase-IMAP-line-length-limit.patch | arnt,2015-03-12 15:39 | Patch to solve. | ||
| Messages (9) | |||
|---|---|---|---|
| msg237950 -(view) | Author: Arnt Gulbrandsen (arnt)* | Date: 2015-03-12 15:39 | |
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. | |||
| msg237967 -(view) | Author: R. David Murray (r.david.murray)* | Date: 2015-03-12 17:47 | |
Gmail breaks the standards again, eh? I suppose we'll have to accommodate them ;) | |||
| msg237985 -(view) | Author: Arnt Gulbrandsen (arnt)* | Date: 2015-03-12 20:54 | |
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. | |||
| msg237988 -(view) | Author: R. David Murray (r.david.murray)* | Date: 2015-03-12 21:32 | |
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. | |||
| msg238933 -(view) | Author: R. David Murray (r.david.murray)* | Date: 2015-03-22 20:07 | |
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. | |||
| msg238937 -(view) | Author: Roundup Robot (python-dev) | Date: 2015-03-22 20:21 | |
New changeseta56aa567072c by R David Murray in branch '2.7':#23647: Increase imaplib's MAXLINE to accommodate modern mailbox sizes.https://hg.python.org/cpython/rev/a56aa567072cNew changesetc1348ada8fc6 by R David Murray in branch '3.4':#23647: Increase imaplib's MAXLINE to accommodate modern mailbox sizes.https://hg.python.org/cpython/rev/c1348ada8fc6New changesetbe6c4569f845 by R David Murray in branch 'default':Merge:#23647: Increase imaplib's MAXLINE to accommodate modern mailbox sizes.https://hg.python.org/cpython/rev/be6c4569f845 | |||
| msg238990 -(view) | Author: Arnt Gulbrandsen (arnt)* | Date: 2015-03-23 08:47 | |
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.) | |||
| msg239123 -(view) | Author: R. David Murray (r.david.murray)* | Date: 2015-03-24 14:10 | |
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. | |||
| msg239128 -(view) | Author: Arnt Gulbrandsen (arnt)* | Date: 2015-03-24 14:29 | |
Length limits has actually been discussed and rejected; noone had a proposal that solved more problems than it introduced. | |||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:58:13 | admin | set | github: 67835 |
| 2022-03-19 20:12:11 | iritkatriel | set | status: open -> closed resolution: fixed stage: needs patch -> resolved |
| 2015-03-24 14:29:22 | arnt | set | messages: +msg239128 |
| 2015-03-24 14:10:13 | r.david.murray | set | messages: +msg239123 |
| 2015-03-23 08:47:08 | arnt | set | messages: +msg238990 |
| 2015-03-22 20:35:43 | r.david.murray | set | keywords: -patch stage: commit review -> needs patch |
| 2015-03-22 20:21:20 | python-dev | set | nosy: +python-dev messages: +msg238937 |
| 2015-03-22 20:07:02 | r.david.murray | set | messages: +msg238933 |
| 2015-03-12 21:32:19 | r.david.murray | set | messages: +msg237988 |
| 2015-03-12 20:54:01 | arnt | set | messages: +msg237985 |
| 2015-03-12 17:47:26 | r.david.murray | set | stage: commit review |
| 2015-03-12 17:47:06 | r.david.murray | set | title: imaplib.py MAXLINE value is too low for 2015 (patch attached) -> imaplib.py MAXLINE value is too low for gmail nosy: +barry,r.david.murray messages: +msg237967 versions: + Python 3.5 components: + email |
| 2015-03-12 15:39:25 | arnt | create | |