>> Upon investigation, one finds the reported RFC822.SIZE constantly >> truncates at part 150 of multipart/digest, no matter how the content >> differs (except if the total message size is small, causing the bug to >> not be triggered.)
SV> Correct. To prevent denial-of-service attacks against the RFC 822 SV> parser, the maximum number of parsed MIME entities has a hard upper SV> limit. SV> Not a bug, but perhaps the maximum upper limit should be raised. Both squirrelmail and roundcube believe courier-imap's fudged RFC822.SIZE reports and truncate mail accordingly, as does fetchmail etc., except getmail thank goodness, which however I cannot use from a public (webmail) terminal. I have an idea: courier-imap should just tell the correct RFC822.SIZE, as in this instance ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464016 ) it is just talking to an independent program, e.g., fetchmail. If courier-imap wants to give wrong RFC822.SIZEs to protect some internal component of itself, it should only do so when talking to that component of itself, not when talking to the outside world, I suppose. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
