https://bugs.kde.org/show_bug.cgi?id=340321
--- Comment #5 from [email protected] --- The manual python check was broken anyway since it did not convert newlines to CRLF. I think the fix in enigmail was commit http://sourceforge.net/p/enigmail/source/ci/8d7fa201ba8bda6f33df348d83923ff0cc876958/tree/package/mimeVerify.jsm?diff=33b2cc9979a933c57430a11ad479108dd04de886 which removes the trailing newline of a mimepart (e.g. if it precedes a mail boundary) Searching for this lead me to http://bugs.python.org/issue14983 which references https://tools.ietf.org/html/rfc3156#page-5 Note: The accepted OpenPGP convention is for signed data to end with a <CR><LF> sequence. Note that the <CR><LF> sequence immediately preceding a MIME boundary delimiter line is considered to be part of the delimiter in [3], 5.1. Thus, it is not part of the signed data preceding the delimiter line. An implementation which elects to adhere to the OpenPGP convention has to make sure it inserts a <CR><LF> pair on the last line of the data to be signed and transmitted (signed message and transmitted message MUST be identical). So I think this was a bug in enigmail but as is noted in the python bug there seems to be a conflict between the spec and the rfc so it is possible other clients suffer the same problem. Which other clients failed to verify the signature? note: this is not my in my field of expertise so it would be great if someone with actual knowledge about this subject could comment on this. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Kdepim-bugs mailing list [email protected] https://mail.kde.org/mailman/listinfo/kdepim-bugs
