On Wednesday 19 October 2005 00:12, MJ Ray wrote:
Of course when we send an ordinary email and think better of something, we might ignore trailing spaces etc. as unimportant - but when kmail notices them in a pgp-mime message, it knows they *must* be represented at the other end, and via 7 bit (rfc3156) too, so it uses qp(rfc2015).
A space, even when trailing, is still a 7-bit character, isn't it? I suspect KMail's misbehaviour is being triggered by a line length
72 but even that shouldn't trigger it. The trailing spaces seen
so far just looked like artefacts of other encoding-fu.
Alas, it is triggered by the trailing spaces (rfc3156: "implementations MUST make sure that no trailing whitespace is present after the MIME encoding has been applied" clashes with the need to protect the signed data).
You have two choices, to strip the trailing spaces prior to signing, or use quoted-printable(or base64 I s'pose).
I guess they choose the Content-Transfer-Encoding route because in a signed message it does not do to mess about with the intended data too much.
Not that I *know* that's why they choose it, mind, but it seems like a realistic possibility.
An interesting quirk(?) in the same part of rfc3156 is that content-transfer-encoding is to be used for messages where any line begins with "From "*, which would presumably trigger the same behaviour in kmail.
Imagine going back over your message trying to work out the problem if *that* was the cause!
Argh.. I must extricate myself from this thread now, I think the last RFC I read actually squoze my other half's birthdate out of the other side of my brain, and I don't like qp myself very much anyway. :)
My foonting turlingdromes,
--
Ten
*apparently "This is because many mail transfer and delivery agents treat "From " (the word "from" followed immediately by a space character) as the start of a new message and thus insert a right angle-bracket (>) in front of any line beginning with "From " to distinguish this case, invalidating the signature"