Re: Bug#6654

[Dave Goldberg <david.goldberg6@verizon.net>]

> Daiki Ueno writes:
>> Dave Goldberg <david.goldberg6@verizon.net> writes:
>>> ... which parses the To: Cc: and Gcc: headers to come up with the list
>>> of recipients and fill in the certfile tags based on that (the Gcc
>>> check just results in a call for my personal key if Gcc exists)
>> 
>> FWIW, you may want to try epg backend of mml-smime.  IIRC, it collects
>> recipient addresses from To/Cc/Bcc, and uses gpgsm (GnuPG's S/MIME tool)
>> to pick certificate by email address.

Thanks for that tip.  I seem to recall a post suggesting the use of
epg and gpgsm for s/mime but was not aware anything had made it into
the code yet.  I'll give it a try.

> Yes, let me second that. I switched from openssl to gpgsm and I think
> it's much more comfortable to use.

> However, the epg backend can't yet decrypt S/MIME messages, but I think
> it just needs a few lines to add this - see the attached patch. At the
> moment it just silently decrypts the message; there should surely be
> some hint that this message was actually decrypted, but first I'd like
> to know if adding the decryption in mm-view.el is the right choice. I'm
> still working on understanding where all the S/MIME decoding is
> happening - it seems there is a lot of historical baggage.

I'll have to try that patch as decrypting and viewing is nearly as
important to me as being able to encrypt :-) If not, do the back ends
allow one to use gpgsm for sending and the old openssl mode for
reading?  Yeah, I know, I'll go RTFS ;-)

Thanks,

-- 
Dave Goldberg
david.goldberg6@verizon.net