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 barry, dkg, mitya57, r.david.murray, sjt
Date 2013-09-21.19:21:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1379791269.19.0.117274462011.issue14983@psf.upfronthosting.co.za>
In-reply-to
Content
Well, there are two problems here, I think (it's been a while since I looked at this): we should indeed be adding a crlf between mime boundary lines.  But also the clients should technically be handling it not being there, as well as the case of extra whitespace being added between the end of the delimiter and the following crlf (which I'm guessing they don't, since the logical way to handle that would be to ignore anything after the end of the delimiter string, in which case this problem wouldn't arise).

Specifically:

   The boundary may be followed by zero or more characters of linear
   whitespace. It is then terminated by either another CRLF...

and:

   NOTE TO IMPLEMENTORS:  Boundary string comparisons must compare the
   boundary value with the beginning of each candidate line.  An exact
   match of the entire candidate line is not required; it is sufficient
   that the boundary appear in its entirety following the CRLF.

So it seems to me that the PGP spec is not RFC conformant...but if we were following the RFC it wouldn't be an issue.
History
Date User Action Args
2013-09-21 19:21:09r.david.murraysetrecipients: + r.david.murray, barry, sjt, mitya57, dkg
2013-09-21 19:21:09r.david.murraysetmessageid: <1379791269.19.0.117274462011.issue14983@psf.upfronthosting.co.za>
2013-09-21 19:21:09r.david.murraylinkissue14983 messages
2013-09-21 19:21:08r.david.murraycreate