I found the problem in camel-smime-context.c and fixed it. Please see
The bug report includes a patch suitable for applying on the
evolution-data-server trunk. If someone can commit it to the trunk (and
to any other "prior supported releases" too if there are any--I don't
know the release schedule) that would be great.
The fix is pretty much a one-liner. I tested it against the trunk and
against Evolution 2.26.1, which is what I apparently got from
I have found a bug in the S/MIME feature of Evolution (2.28.1 and
trunk). Hopefully this should be pretty easy to fix. I tried to file
this as a bug on Bugzilla, but I cannot create an account on
bugzilla.gnome.org--no ping e-mail is received in any of my inboxes,
and I have tried several e-mail addresses with different providers.
When a signed and encrypted message is composed in Evolution, the MIME
content of the EnvelopedData object is formatted with bare linefeeds
(LFs). This is not valid MIME--all MIME messages (and e-mail in
general) is required to use CRLFs as line endings. The outer message,
where the EnvelopedData is base64 encoded, and the inner message
inside the SignedData part, are properly CRLF encoded. It's just the
layer in between.
When an EnvelopedData (encrypted)-only message is composed, and when a
SignedData (signed)-only message is composed, this is not a problem.
How can this be fixed? I have started to look through Evolution to see
if it is easy enough to develop a patch, but the process is taking
Evolution-hackers mailing list