810eaaa9302f7ef480cbd693b71fbcc9ed9cd114
[gpgol.git] / doc / gpgol.texi
1 \input texinfo
2 @documentencoding ISO-8859-1
3 @setfilename gpgol.info
4 @include version.texi
5 @settitle The GpgOL Technical Manual
6
7 @dircategory GnuPG Plugin
8 @direntry
9 * gpgol: (gpgol).              An Outlook Plugin for GnuPG.
10 @end direntry
11
12 @macro clnt
13   @sc{c:} @c
14 @end macro
15 @macro srvr
16   @sc{s:} @c
17 @end macro
18
19
20
21 @c Unify some of the indices.
22 @syncodeindex tp fn
23 @syncodeindex pg fn
24
25 @copying
26 This is @cite{The GpgOL Technical Manual} for @acronym{GpgOL} (version
27 @value{VERSION}, @value{UPDATED-MONTH}).
28
29 @iftex
30 Published by g10 Code GmbH@*
31 Hüttenstr. 61@*
32 40699 Erkrath, Germany
33 @end iftex
34
35 Copyright @copyright{} 2007 g10 Code GmbH
36
37 @quotation
38 Permission is granted to copy, distribute and/or modify this document
39 under the terms of the GNU General Public License as published by the
40 Free Software Foundation; either version 3 of the License, or (at your
41 option) any later version. The text of the license can be found in the
42 section entitled ``Copying''.
43 @end quotation
44 @end copying
45
46 @c
47 @c Titlepage
48 @c
49 @setchapternewpage odd
50 @titlepage 
51 @title The GpgOL Technical Manual
52 @subtitle Version @value{VERSION}
53 @subtitle @value{UPDATED-MONTH}
54
55 @sp 3
56
57 @sp 3
58
59 @author Werner Koch (@email{wk@@gnupg.org})
60
61 @page
62 @vskip 0pt plus 1filll
63 @insertcopying
64 @end titlepage
65
66 @ifnothtml
67 @contents
68 @page
69 @end ifnothtml
70
71 @c @ifhtml
72 @c @center @image{logo}
73 @c @end ifhtml
74
75 @ifnottex
76 @node Top
77 @top 
78
79 @insertcopying
80
81 @noindent
82 This file documents @acronym{GpgOL}; a GnuPG plugin for Microsoft's
83 Outlook MUA.
84 @end ifnottex
85
86
87 @menu
88 * Introduction::                How to use this manual.
89 * Assuan Protocol::             Description of the UI server protocol.
90 * MAPI Properties::             MAPI Properties used by GpgOL.
91 * Registry Settings::           How GpgOL uses the Registry.
92
93 Appendices
94
95 * Copying::                     The GNU General Public License says how you
96                                 can copy and share this manual.
97
98 Indices
99
100 * Concept Index::               Index of concepts and programs.
101 * Function and Data Index::     Index of functions, variables and data types.
102
103 @end menu
104
105 @ifhtml
106 @page
107 @summarycontents
108 @contents
109 @end ifhtml
110
111 @c
112 @c  I N T R O
113 @c
114 @node Introduction
115 @chapter Introduction
116
117 To debug GpgOL you should set the Registry entry
118 @code{HKCU\Software\Gnu\GpgOL:enableDebug} to the string value @code{1}:
119
120 @cartouche
121 @example
122 [HKEY_CURRENT_USER\Software\GNU\GpgOL]
123 "enableDebug"="1"
124 @end example
125 @end cartouche
126
127 This allows easy setting of a debug file by using the extended options
128 menu and enables a few extra menu items.
129
130
131 @c
132 @c  P R O T O C O L  D E S C R I P T I O N
133 @c
134 @node Assuan Protocol
135 @chapter Description of the UI Server Protocol
136
137 This section describes the protocol used between @acronym{GpgOL} and the
138 User Interface Server (UI server).  All cryptographic operations are
139 done by this server and the server is responsible for all dialogs.  If a
140 a server is not available, @acronym{GpgOL} can only use a very limited
141 internal crypto server.
142
143 We assume that the connection has already been established; see the
144 Assuan manual for details.
145
146 @menu
147 * ENCRYPT::                  Encrypt a message.
148 * SIGN::                     Sign a message.
149 * DECRYPT::                  Decrypt a message.
150 * VERIFY::                   Verify a message.
151 * Miscellaneous Commands::   Commands not related to a specific operation.
152 @end menu
153
154
155
156 @node ENCRYPT
157 @section Encrypt a Message
158
159 Before encryption can be done the recipients must be set using the
160 command:
161
162 @deffn Command RECIPIENT @var{string}
163
164 Set the recipient for the encryption.  @var{string} is an RFC-2822
165 recipient name ("mailbox" as per section 3.4).  This command may or may
166 not check the recipient for validity right away; if it does not all
167 recipients are expected to be checked at the time of the @code{ENCRYPT}
168 command.  All @code{RECIPIENT} commands are cumulative until a
169 successful @code{ENCRYPT} command or until a @code{RESET} command.
170 Linefeeds are obviously not allowed in @var{string} and should be folded
171 into spaces (which are equivalent).
172 @end deffn
173
174 @noindent
175 To tell the server the source and destination of the data, the next two
176 commands are to be used:
177
178 @deffn Command INPUT FD=@var{n}
179 Set the file descriptor for the message to be encrypted to @var{n}.  The
180 message send to the server is binary encoded. 
181
182 GpgOL is a Windows only program, thus @var{n} is not a libc file
183 descriptor but a regular system handle.  Given that the Assuan
184 connection works over a socket, it is not possible to use regular
185 inheritance to make the file descriptor available to the server.
186 Thus @code{DuplicateHandle} needs to be used to duplicate a handle
187 to the server process.  This is the reason that the server needs to
188 implement the @code{GETINFO pid} command.  Sending this command a second
189 time replaces the file descriptor set by the last one.
190 @c If @var{n} is not given, this commands uses the
191 @c %last file descriptor passed to the application.
192 @c %@xref{fun-assuan_sendfd, ,the assuan_sendfd function,assuan,the
193 @c %Libassuan manual}, on how to do descriptor passing.
194 @end deffn
195
196 @deffn Command OUTPUT FD=@var{n}
197 Set the file descriptor to be used for the output (i.e. the encrypted
198 message) to @var{n}.  For OpenPGP, the output needs to be ASCII armored;
199 for CMS, the output needs to be Base-64 encoded.  For details on the
200 file descriptor, see the @code{INPUT} command.
201 @end deffn
202
203 @noindent  
204 The setting of the recipients, the data source and destination may
205 happen in any order, even intermixed.  If this has been done the actual
206 encryption operation is called using:
207
208 @deffn Command ENCRYPT -@w{}-protocol=@var{name}
209
210 This command reads the plaintext from the file descriptor set by the
211 @code{INPUT} command, encrypts it and writes the ciphertext to the file
212 descriptor set by the @code{OUTPUT} command.  The server may (and
213 should) overlap reading and writing.  The recipients used for the
214 encryption are all the recipients set so far.  If any recipient is not
215 usable the server should take appropriate measures to notify the user
216 about the problem and may cancel the operation by returning an error
217 code.  The used file descriptors are void after this command; the
218 recipient list is only cleared if the server returns success.
219
220 @noindent
221 Because GpgOL uses a streaming mode of operation the server is not
222 allowed to auto select the protocol and must obey to the mandatory
223 @var{protocol} parameter:
224
225 @table @code
226 @item OpenPGP
227 Use the OpenPGP protocol (RFC-2440).
228 @item CMS
229 Use the CMS (PKCS#7) protocol (RFC-3852).
230 @end table
231
232 @end deffn
233
234 To support automagically selection of the protocol depending on the
235 selected keys, the server MAY implement the command:
236
237 @deffn Command PREP_ENCRYPT [-@w{}-protocol=@var{name}]
238
239 This commands considers all recipients set so far and decides whether it
240 is able to take input and start the actual decryption.  This is kind of
241 a dry-run @command{ENCRYPT} without requiring or using the input and
242 output file descriptors.  The server shall cache the result of any user
243 selection to avoid asking this again when the actual @command{ENCRYPT}
244 command is send.  The @option{--protocol} option is optional; if it is
245 not given, the server should allow the user to select the protocol to be
246 used based on the recipients given or by any other means.
247
248 If this command is given again before a successful @command{ENCRYPT}
249 command, the second one takes effect. 
250
251 Before sending the OK response the server shall tell the client the
252 protocol to be used (either the one given by the argument or the one
253 selected by the user) by means of a status line:
254 @end deffn
255
256 @deffn {Status line} PROTOCOL @var{name}
257 Advise the client to use the protocol @var{name} for the
258 @command{ENCRYPT} command.  The valid protocol names are listed under
259 the description of the @command{ENCRYPT} command.  The server shall emit
260 exactly one PROTOCOL status line.
261 @end deffn
262
263 @noindent
264 Here is an example of a complete encryption sequence; client lines are
265 indicated by a @sc{c:}, server responses by @sc{c:}:
266
267 @smallexample
268 @group
269   @clnt RESET
270   @srvr OK
271   @clnt RECIPIENT foo@@example.net
272   @srvr OK
273   @clnt RECIPIENT bar@@example.com
274   @srvr OK
275   @clnt PREP_ENCRYPT
276   @srvr S PROTOCOL OpenPGP
277   @srvr OK
278   @clnt INPUT FD=17
279   @srvr OK
280   @clnt OUTPUT FD=18
281   @srvr OK
282   @clnt ENCRYPT
283   @srvr OK
284 @end group
285 @end smallexample
286
287
288
289 @node SIGN
290 @section Sign a Message
291
292 The server needs to implement opaque signing as well as detached
293 signing.  Due to the nature of OpenPGP messages it is always required to
294 send the entire message to the server; sending just the hash is not
295 possible.  The following two commands are required to set the input and
296 output file descriptors:
297
298 @deffn Command INPUT FD=@var{n}
299 Set the file descriptor for the message to be signed to @var{n}.  The
300 message send to the server is binary encoded.  For details on the file
301 descriptor, see the description of @code{INPUT} in the @code{ENCRYPT}
302 section.
303 @end deffn
304
305 @deffn Command OUTPUT FD=@var{n}
306 Set the file descriptor to be used for the output.  The output is either
307 the complete signed message or in case of a detached signature just that
308 detached signature.  For OpenPGP, the output needs to be ASCII armored;
309 for CMS, the output needs to be Base-64 encoded.  For details on the
310 file descriptor, see the @code{INPUT} command.
311 @end deffn
312
313 @noindent
314 To allow the server the selection of a non-default signing key the
315 client may optionally use the command:
316
317 @deffn Command SENDER @var{email}
318 @var{email} is the plain ASCII encoded address ("addr-spec" as per
319 RFC-2822) enclosed in angle brackets.  The address set with this command
320 is valid until a successful @code{SIGN} command or until a @code{RESET}
321 command.  A second command overrides the effect of the first one; if
322 @var{email} is not given the server shall use the default signing key.
323 The server shall also suggest a protocol to use for signing.  The client
324 may use this suggested protocol on its own discretion.  The same status
325 line as with PREP_ENCRYPT is used for this.
326 @end deffn
327
328 @noindent
329 The signing operation is then initiated by:
330
331 @deffn Command SIGN -@w{}-protocol=@var{name} [-@w{}-detached] 
332 Sign the data set with the @code{INPUT} command and write it to the sink
333 set by OUTPUT.  @var{name} is the signing protocol used for the
334 message. For a description of the allowed protocols see the
335 @code{ENCRYPT} command.  With option @code{--detached} given, a detached
336 signature is created; this is actually the usual way the command is
337 used.
338 @end deffn
339
340 @noindent
341 The client expects the server to send at least this status information
342 before the final OK response:
343
344 @deffn {Status line} MICALG @var{string}
345 The @var{string} represents the hash algorithm used to create the
346 signature. It is used with MOSS style signature messages and defined by
347 PGP/MIME (RFC-3156) and S/MIME (RFC-3851).  The GPGME library has a
348 supporting function @code{gpgme_hash_algo_name} to return the algorithm
349 name as a string.  This string needs to be lowercased and for OpenPGP
350 prefixed with "@code{pgp-}".
351 @end deffn
352
353
354
355 @node DECRYPT
356 @section Decrypt a Message
357
358 Decryption may include the verification of OpenPGP messages.  This is
359 due to the often used combined signing/encryption modus of OpenPGP.  The
360 client may pass an option to the server to inhibit the signature
361 verification.  The following two commands are required to set the input
362 and output file descriptors:
363
364 @deffn Command INPUT FD=@var{n}
365 Set the file descriptor for the message to be decrypted to @var{n}.  The
366 message send to the server is either binary encoded or --- in the case
367 of OpenPGP --- ASCII armored.  For details on the file descriptor, see
368 the description of @code{INPUT} in the @code{ENCRYPT} section.
369 @end deffn
370
371 @deffn Command OUTPUT FD=@var{n}
372 Set the file descriptor to be used for the output. The output is binary
373 encoded. For details on the file descriptor, see the description of
374 @code{INPUT} in the @code{ENCRYPT} section.
375 @end deffn
376
377 @noindent
378 The decryption is started with the command:
379
380 @deffn Command DECRYPT -@w{}-protocol=@var{name} [-@w{}-no-verify]
381 @var{name} is the encryption protocol used for the message. For a
382 description of the allowed protocols see the @code{ENCRYPT} command.
383 This argument is mandatory.  If the option @option{--no-verify} is given,
384 the server should not try to verify a signature, in case the input data
385 is an OpenPGP combined message.
386 @end deffn
387
388
389 @node VERIFY
390 @section Verify a Message
391
392 The server needs to support the verification of opaque signatures as
393 well as detached signatures.  The kind of input sources controls what
394 kind message is to be verified. 
395
396 @deffn Command MESSAGE FD=@var{n}
397 This command is used with detached signatures to set the file descriptor
398 for the signed data to @var{n}. The data is binary encoded (used
399 verbatim).  For details on the file descriptor, see the description of
400 @code{INPUT} in the @code{ENCRYPT} section.
401 @end deffn
402
403 @deffn Command INPUT FD=@var{n}
404 Set the file descriptor for the opaque message or the signature part of
405 a detached signature to @var{n}.  The message send to the server is
406 either binary encoded or -- in the case of OpenPGP -- ASCII armored.
407 For details on the file descriptor, see the description of @code{INPUT}
408 in the @code{ENCRYPT} section.
409 @end deffn
410
411 @deffn Command OUTPUT FD=@var{n}
412 Set the file descriptor to be used for the output. The output is binary
413 encoded and only used for opaque signatures.  For details on the file
414 descriptor, see the description of @code{INPUT} in the @code{ENCRYPT}
415 section.
416 @end deffn
417
418 @noindent
419 The verification is then started using:
420
421 @deffn Command VERIFY -@w{}-protocol=@var{name} [-@w{}-silent]
422 @var{name} is the signing protocol used for the message. For a
423 description of the allowed protocols see the @code{ENCRYPT} command.
424 This argument is mandatory.  Depending on the combination of
425 @code{MESSAGE} @code{INPUT} and @code{OUTPUT} commands, the server needs
426 to select the appropriate verification mode:
427
428 @table @asis
429 @item MESSAGE and INPUT
430 This indicates a detached signature.  Output data is not applicable.
431 @item INPUT 
432 This indicates an opaque signature.  As no output command has been given,
433 the server is only required to check the signature.
434 @item INPUT and OUTPUT
435 This indicates an opaque signature.  The server shall write the signed
436 data to the file descriptor set by the output command.  This data shall
437 even be written if the signatures can't be verified.
438 @end table
439 @end deffn
440
441 With @option{--silent} the server shall not display any dialog; this is
442 for example used by the client to get the content of opaque signed
443 messages. The client expects the server to send at least this status
444 information before the final OK response:
445
446 @deffn {Status line} SIGSTATUS @var{flag} @var{displaystring}
447 Returns the status for the signature and a short string explaining the
448 status.  Valid values for @var{flag} are:
449
450 @table @code
451 @item none
452 The message has a signature but it could not not be verified due to a
453 missing key.
454 @item green
455 The signature is fully valid.
456 @item yellow
457 The signature is valid but additional information was shown regarding the
458 validity of the key.
459 @item red
460 The signature is not valid. 
461 @end table
462
463 @var{displaystring} is a percent-and-plus-encoded string with a short
464 human readable description of the status.  For example
465
466 @smallexample
467 S SIGSTATUS green Good+signature+from+Keith+Moon+<keith@@example.net>
468 @end smallexample
469
470 Note that this string needs to fit into an Assuan line and should be
471 short enough to be displayed as short one-liner on the clients window.
472 As usual the encoding of this string is UTF-8 and it should be send in
473 its translated form.
474
475 The server shall send one status line for every signature found on the
476 message.
477
478
479 @end deffn
480
481
482
483 @c
484 @c M I S C E L L A N E O U S  C O M M A N D S
485 @c
486 @node Miscellaneous Commands
487 @section Miscellaneous Commands
488
489 The server needs to implement the following commands which are not
490 related to a specific command:
491
492 @deffn Command GETINFO @var{what}
493 This is a multi purpose command, commonly used to return a variety of
494 information.  The required subcommands as described by the @var{what}
495 parameter are:
496
497 @table @code
498 @item pid
499 Return the process id of the server in decimal notation using an Assuan
500 data line.
501 @end table
502 @end deffn
503
504
505 @noindent
506 To allow the server to pop up the windows in the correct relation to the
507 client, the client is advised to tell the server by sending the option:
508
509 @deffn {Command option} window-id @var{number} 
510 The @var{number} represents the native window ID of the clients current
511 window.  On Windows systems this is a windows handle (@code{HWND}) and
512 on X11 systems it is the @code{X Window ID}.  The number needs to be
513 given as a hexadecimal value so that it is easier to convey pointer
514 values (e.g. @code{HWND}).
515 @end deffn
516
517
518 @noindent
519 GpgOL features a button to invoke the certificate manager.  To do this
520 it uses the Assuan command:
521
522 @deffn Command START_KEYMANAGER
523 The server shall pop up the main window of the key manager (aka
524 certificate manager).  The client expects that the key manager is brought
525 into the foregound and that this command immediatley returns (does not
526 wait until the key manager has been fully brought up).
527 @end deffn
528
529 @c xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
530 @c
531 @c  M A P I  P r o p e r t i e s
532 @c
533 @c xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
534 @node MAPI Properties
535 @chapter MAPI Properties used by GpgOL
536
537 GpgOL uses a some custom MAPI properties in the named properties range.
538 Thus their actual numbers are determined at runtime and only the names
539 should be used.  The GUID assigned to these properties is
540 @code{31805ab8-3e92-11dc-879c-00061b031004}.
541
542 @table @code
543
544 @item GpgOL Attach Type
545 This is a property of type LONG and used to further describe the
546 attachments created by GpgOL.  These values are used:
547
548   @table @asis
549   @item ATTACHTYPE_MOSS = 1
550   The attachment contains the original MOSS message.  That is either an
551   S/MIME or a PGP/MIME message in its original RFC-2822 format (but only
552   with the relevant MIME parts of the main header).
553
554   @item ATTACHTYPE_FROMMOSS = 2
555   The attachment has been created from the original MOSS attachment.  It
556   will automagically be recreated as needed.  If the atatchment has
557   been created from an encrypted message, it is saved re-encrypted under
558   a non-permanent session key.  This session key is valid as long as the
559   current Outlook porcess exists.
560
561   @item ATTACHTYPE_MOSSTEMPL = 3
562   The attachment has been created in the course of sending a message.
563
564   @item ATTACHTYPE_PGPBODY = 4
565   The attachment contains the original PGP message body of PGP inline
566   encrypted messages.  We need to save this away because it may happen
567   that in the course of displaying the plaintext Outlook overwrites the
568   actual body due to internal syncronization.
569   @end table
570
571 @item GpgOL Sig Status
572 This is a property of type STRING8 and used to cache the result of the
573 last signature verification.  It is used with the actual message and
574 consists of a single character, a space and a human readable string
575 (utf-8 encoded).  The first character is used as a machine processable
576 flag indicating the status.  These values are defined:
577
578   @table @code
579   @item #
580   The message is not of interest to us.  GpgOL may flag any message with
581   this signature status to avoid extra processing for messages already
582   known not to need any processing by GpgOL.
583
584   @item @@
585   The message has been created and signed or encrypted by GpgOL. 
586  
587   @item ?
588   The signature status has not been checked.  This is for example used
589   if the public key to be used for the verification could not be found.
590
591   @item !
592   The signature verified okay and is deemed to be fully valid.
593
594   @item ~
595   The signature was not fully verified.  This often means that the full
596   result information of the signature verification needs to be
597   considered to decide the actual validity.  Used for example if the
598   signing key has expired
599
600   @item -
601   The signature is bad.  Either this means the message has been tampered
602   with or an intermediate message relay has accidently changed
603   the message (e.g. due to recoding).
604   
605   @end table
606
607 @item GpgOL Protect IV
608 This binary property is used to store the initialization vector of an
609 re-encrypted attachment.  The existence of this property indicates that
610 the attachment has been encrypted under the non-permanent session key.
611
612 @item GpgOL Charset
613 This is a property of type STRING8 and used to describe the character
614 set of an attachment or of the body.  If this propery is missing the
615 default of UTF-8 is assumed.
616
617 @item GpgOL Last Decrypted
618 This binary property is used on the message to save a session marker to
619 tell GpgOL whether the message as already been decrypted.  If this
620 property does not exists or the session marker does not macth the one of
621 the current session, GpgOL needs to decrypt it again.
622
623 @item GpgOL MIME Info
624 This property is of type STRING8 and used to store the MIME structure of
625 the orginal message.  The content are lines of colon delimited fields.
626 The specification has not yet been finished.
627
628 @end table
629
630
631 @c xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
632 @c
633 @c  R e g i s t r y  S  e t t i n g s
634 @c
635 @c xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
636 @node Registry Settings
637 @chapter How GpgOL uses the Registry
638
639 This is a list of registry entries GpgOL knows about. 
640
641 @table @code
642
643 @item HKLM\Software\GNU\GnuPG:Install Directory
644 This is used by GnuPG to describe the directory where GnupG has been
645 installed.  GpgOL requires this to get the location of the localedir
646 which is used to show translated strings (@file{gpgol.mo}).  It is
647 further used to check whether GnuPG has been installed at all.
648
649 @item HKCU\Software\GNU\GnuPG:UI Server
650 If the UI server could not be connected, GpgOL tries to start the one
651 given in this entry.  It is assumed that the UI server is stored in the
652 @code{Install Directory} (as described above).  This Registry entry
653 gives the actual command name relative to this directory.  If the key
654 does not exist, is is first searched below @code{HKLM} and then it
655 defaults to @code{bin/kleopatra.exe} (FIXME: The final name will be just
656 @code{kleopatra.exe}).
657
658 @item HKCU\Software\GNU\GpgOL:enableDebug
659 Setting this key to the string @code{1} enables a few extra features in
660 the UI, useful only for debugging.  Setting it to values larger than 1
661 make the log file output more verbose; these are actually bit flags
662 according to the following table (which may change with any release):
663 @table @code
664 @item 2  (0x0002)
665 Tell what the Assuan I/O scheduler is doing.
666 @item 4  (0x0004)
667 Even more verbose Assuan I/O scheduler reporting. 
668 @item 8  (0x0008)
669 Tell what the filter I/O system is doing.
670 @item 16 (0x0010)
671 Tell how the filter I/O locks the resources.
672 @item 32 (0x0020)
673 Tell about resource allocation.
674 @item 64 (0x0040)
675 Tell about command events.
676 @end table
677 You may use the regular C-syntax for entering the value.
678
679
680 @itemx HKCU\Software\GNU\GpgOL:logFile
681 If the value is not empty, GpgOL takes this as a log file and appends
682 debug information to this file.  The file may get very large.
683
684 @itemx HKCU\Software\GNU\GpgOL:compatFlags
685 This is a string consisting of @code{0} and @code{1} to enable certain
686 compatibility flags.  Not generally useful; use the source for a
687 description.
688
689 @item HKCU\Software\GNU\GpgOL:enableSmime   
690 @itemx HKCU\Software\GNU\GpgOL:defaultProtocol
691 @itemx HKCU\Software\GNU\GpgOL:encryptDefault
692 @itemx HKCU\Software\GNU\GpgOL:signDefault   
693 @itemx HKCU\Software\GNU\GpgOL:previewDecrypt
694 @itemx HKCU\Software\GNU\GpgOL:storePasswdTime
695 @itemx HKCU\Software\GNU\GpgOL:encodingFormat 
696 @itemx HKCU\Software\GNU\GpgOL:defaultKey   
697 @itemx HKCU\Software\GNU\GpgOL:enableDefaultKey
698 @itemx HKCU\Software\GNU\GpgOL:preferHtml 
699 These registry keys store the values from the configuration dialog.
700
701 @item HKCU\Software\GNU\GpgOL:svnRevision
702 When leaving GpgOL's options dialog, the SVN revision number of the current
703 version will be stored in this entry.  This is used to display a note
704 after software upgrades.
705
706
707 @end table
708
709
710
711 @c xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
712 @c
713 @c   A P P E N D I X
714 @c 
715 @c xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
716
717 @include gpl.texi
718
719 @c
720 @c  I N D E X E S
721 @c
722 @node Concept Index
723 @unnumbered Concept Index
724 @printindex cp
725 @node Function and Data Index
726 @unnumbered Function and Data Index
727 @printindex fn
728
729 @bye
730
731 @c xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
732 @c
733 @c E D I T O R ' S   A T T I C
734 @c 
735 @c xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
736
737 What about the message class mangling?
738
739 * On receiving a new message GpgOL checks the MAPI message class
740   property of the message and if this is an S/MIME message class
741   ("IPM.Note.SMIME"), it is changed to a GpgOL specific one
742   ("IPM.Note.GpgOL").  This change is required so that OL does not not
743   apply its own S/MIME handler to the message but leaves it unchanged in
744   the message store.
745
746 * For ease of implementarion the same thing applies to PGP messgaes,
747   although OL would not touch these messages.
748
749 * When reading a message GpgOL quickly checks the message class and if
750   it is "IPM.Note.GpgOL" it will hook itself into the code path and
751   decrypt/verify the message.
752
753 * Messages already in the message store before GpgOL was installed are
754   handled diffwerently: Here an Outlook specific event is used to change
755   the message class when browsing the messages folder.  This code path
756   is not fully ready as it requires the installation of an ECF(ile)
757   which has to be done manually as of now.
758
759 * If GpgOL is deinstalled, the existing S/MIME messages can't be
760   decrypted or verified by Outlook's internal S/MIME support.
761   Multipart/signed messages are still readable, though.  We plan to add
762   a little tool for changing the GpgOL message classes back to
763   "IPM.Note.SMIME" which in turn allows using internal S/MIME support
764   again.
765
766
767
768
769 @c Local Variables:
770 @c coding: latin-1
771 @c End: