Re: Crypto-MIME in GNUS

[Simon Josefsson <simon@josefsson.org>]

"Georg C. F. Greve" <greve@gnu.org> writes:

>  >> The biggest problem was that the gnus crypto function didn't work
>  >> since it gave mailcrypt the buffer to encrypt that didn't contain
>  >> headers so mailcrypt had no way to determine who to encrypt it
>  >> for.
> 
>  sj> Weird, this is definitely not the case for me.  Could you tell
>  sj> why `message-options-set-recipient' function fail to figure out
>  sj> recipients?  Or if there's some problem in mml2015 when mailcrypt
>  sj> is given the information snarfed from the *mail* buffer?
> 
> I'm suspecting you are not using Crypto-*MIME* but rather encrypt the
> whole buffer as it is (which is the old way gnus used to do it). I
> have been doing it myself but a lot of non-gnus users have problems
> with it... also if there is a standard one should stick to it.

Well, there are at least two standards here. :-)

FWIW, people I communicate with that uses Outlook and some PGP plugin
does not handle PGP/MIME (RFC2015).  The plugin perform PGP-operations
on each MIME part individually and only insert the PGP output instead
of the MIME content of that part.  I don't think it even modifies MIME
headers.  Yuk.

> And when using Crypto-MIME, mailcrypt never ever sees the headers
> (which is as it should be) - it is gnus' job to figure out the
> recipients and the last time I tried (CVS version about three months
> ago), it didn't do it. So I wrote these other functions.

Ok -- that's what I meant, this works for me with current Gnus.

>  >> Also when I got it to work half-way I realized that CC and BCC
>  >> were ignored.
> 
>  sj> Right, `message-options-set-recipient' only look at the To:
>  sj> header.
> 
> Exactly. Which is stupid. Unless the others are also you (which is not
> the standard case, imho), they won't be able to read the mail then. So
> why bother sending it to them at all?

I've no idea. :-)  I changed it, it should look at Cc and Bcc now.

>  >> Also I wanted a nice way to determine whether to encrypt or sign
>  >> that I could toggle while composing the mail.
> 
>  sj> Hm, `C-c RET s p' or `C-c RET c p'?
> 
> ...does pretty much the same. But only almost. It only encrypts the
> following part, not the whole message. When I encrypt I normally want
> the whole thing encrypted... otherwise you run a high chance to
> insert another part and accidentally lose encryption that way.

Ah, yes, I agree.  Those commands are made to only sign or encrypt the
current MML part, but maybe that's not very intuitive.  Perhaps they
could be changed?