Gnus development mailing list
 help / color / mirror / Atom feed
* Crypto MIME issues... two bugs in gnus
@ 2000-11-23 21:48 Georg C. F. Greve
  0 siblings, 0 replies; only message in thread
From: Georg C. F. Greve @ 2000-11-23 21:48 UTC (permalink / raw)
  Cc: ShengHuo ZHU


[-- Attachment #1.1: Type: text/plain, Size: 3343 bytes --]

Hi!

Alright, I did some searching in the code for the reasons of my
encryption problems with the recent gnus and found them in the gnus
code. 

 Problem 1: when sending out encrypted mail, the Cc and Bcc fields get
                ignored

 Problem 2: I never get prompted for recipients in order to make sure
                they are correct


I will confine myself to mailcrypt here as gpg.el does not work for me
and mailcrypt does support GPG very well... but the problems would be
similar with gpg.el.


When doing proper MIME crypto mails, gnus calls mc-encrypt-generic
which takes the recipients as an argument and basically only asks for
Recipients if there are none specified. 

If I put this into my .gnus:

--------

 (defun mc-encrypt-generic (&optional recipients scheme start end from sign)
   "*Generic function to encrypt a region of data."
  
   (save-excursion
     (or start (setq start (point-min-marker)))
     (or (markerp start) (setq start (copy-marker start)))
     (or end (setq end (point-max-marker)))
     (or (markerp end) (setq end (copy-marker end)))
     (run-hooks 'mc-pre-encryption-hook)
    
     ;; this will force it to prompt us for recipients:
     (setq recipients
 	   (mc-cleanup-recipient-headers (read-string "Recipients: " recipients)))
    
     (or scheme (setq scheme mc-default-scheme))
     (if (funcall (cdr (assoc 'encryption-func (funcall scheme)))
	 	 recipients start end from sign)
	 (progn
	   (run-hooks 'mc-post-encryption-hook)
            t))))

--------

(essentially the original function - only modified in so far as it
 ALWAYS asks for recipients)

, it does solve Problem 2 for me. There is no other way because only
the mc-encrypt-message can be made to ask for recipients.

But this still leaves Problem 1. Well. Mailcrypt only gets the CONTENT
stripped of all headers. Which means that it has no chance to guess
the recipients - this would be the job of gnus in this case. It seems
that it is done in mml-generate-mime-1 - which apparently only pays
attention to the "To:" field.  Unfortunately the function is pretty
big and I would not like to create my own version of it.

So as far as I can see the switch to Crypto MIME introduced two "bugs"
in gnus (they are not really bugs - more like missing features that
"became" missing by going to Crypto MIME):

        1.) When gathering the recipients, gnus should pay attention
          to the Cc: and Bcc: fields.

        2.) There should be an option to make gnus ask for crypto
          recipients. Possibly giving all the To:, Cc:, Bcc: addresses
          as default.


Oh. And one other thing. When doing:

 <#multipart encrypt=pgpmime recipients="someone@someplace">

gnus does not pass along the recipients parameter. I can see that
because my function change shown above allows me to see the recipients
passed to mc-encrypt-generic. They are ALWAYS just the people on the
To: line regardless of Cc:, Bcc: or "recipients" option.

Alright, I hope this will prove helpful enough to solve the remaining
problems quickly...

Regards,
                Georg

-- 
Georg C. F. Greve <greve@gnu.org>
the monthly GNU forum in English, German, 
French, Spanish and Japanese. Check it out 
at http://brave-gnu-world.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 268 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2000-11-23 21:48 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-11-23 21:48 Crypto MIME issues... two bugs in gnus Georg C. F. Greve

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).