This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients Ingo Ruhnke, berker.peksag, christian.heimes, doko, gnarvaja, r.david.murray, rblank
Date 2015-06-28.15:40:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1435506038.18.0.392739588266.issue23906@psf.upfronthosting.co.za>
In-reply-to
Content
The RFC is in fact not clear on this point.  It is entirely possible to read it as saying that each line of a mulitline response is limited to 512 octets.  I agree, however, that that is not the most reasonable interpretation.  Instead, the line length of RETR message lines should be governed by RFC 5322, which specifies a maximum line length of 998 octets.

That, however, means that technically dovecot is still broken, since 2048 is quite a bit larger than 998.  In reality, it means that the *internet* is broken, in that I presume the root of the problem is that there are mail originators out there that are not obeying RFC 5322 (and its predecessors...this limit goes back to 821/822).

We use 8192 in smtplib, and that hasn't caused any problems...but then again smtplib is originating email, not receiving it.  The IMAP protocol has its own problems, quite aside from the length of message body lines, so we ended up with a very large MAXLINE there.  It may be that we have no choice except to do something similar in poplib.

An interesting question in this context is what smtp servers do. since if anyone was going to reject messages with overlong lines, it would be the smtp server's job to do it.
History
Date User Action Args
2015-06-28 15:40:38r.david.murraysetrecipients: + r.david.murray, doko, rblank, christian.heimes, berker.peksag, gnarvaja, Ingo Ruhnke
2015-06-28 15:40:38r.david.murraysetmessageid: <1435506038.18.0.392739588266.issue23906@psf.upfronthosting.co.za>
2015-06-28 15:40:38r.david.murraylinkissue23906 messages
2015-06-28 15:40:37r.david.murraycreate