xemacs-beta: man/mailcrypt.texi comparison

comparison man/mailcrypt.texi @ 0:376386a54a3c r19-14

Import from CVS: tag r19-14

author	cvs
date	Mon, 13 Aug 2007 08:45:50 +0200
parents
children

comparison

equal deleted inserted replaced

--1:000000000000
+:376386a54a3c
+\input texinfo @c -*-Texinfo-*-
+@c tighten default spacing
+@c @parskip 5pt plus 1 pt
+@c @secheadingskip 10pt plus 6pt minus 3pt
+@c @subsecheadingskip 8pt plus 6pt minus 3pt
+@c @singlespace
+@c %**start of header
+@setfilename ../info/mailcrypt.info
+@settitle @value{TITLE}
+@setchapternewpage off
+@c %**end of header
+@syncodeindex ky cp
+@syncodeindex vr cp
+@syncodeindex fn cp
+@set TITLE Mailcrypt
+@set VERSION 3.4
+@set UPDATED October 10, 1995
+@ifinfo
+This documentation describes Mailcrypt version @value{VERSION}.  This
+documentation was last updated on @value{UPDATED}.
+Copyright 1995 Patrick J. LoPresti
+The Mailcrypt program and this manual are published as free software.
+You may redistribute and/or modify them under the terms of the GNU
+General Public License as published by the Free Software Foundation;
+either version 2, or (at your option) any later version.
+Mailcrypt is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+You should have received a copy of the GNU General Public License along
+with GNU Emacs; see the file COPYING.  If not, write to the Free
+Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+@end ifinfo
+@titlepage
+@title Mailcrypt: An EMACS Interface to PGP
+@subtitle Version @value{VERSION}
+@subtitle @value{UPDATED}
+@author Patrick J. LoPresti <patl@@lcs.mit.edu>
+@c Copyright page
+@page
+@vskip 0pt plus 1filll
+Copyright @copyright{} 1995 Patrick J. LoPresti
+The Mailcrypt program and this documentation are published as free
+software.  You may redistribute and/or modify them under the terms of
+the GNU General Public License as published by the Free Software
+Foundation; either version 2, or (at your option) any later version.
+Mailcrypt is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+You should have received a copy of the GNU General Public License along
+with GNU Emacs; see the file COPYING.  If not, write to the Free
+Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+@end titlepage
+@ifinfo
+@node Top, Introduction, (dir), (dir)
+@top Mailcrypt
+Mailcrypt is an Emacs Lisp package which provides a simple but powerful
+interface to cryptographic functions for mail and news.
+This documentation describes Mailcrypt version @value{VERSION}.  The
+documentation was last updated on @value{UPDATED}.
+@end ifinfo
+@menu
+* Introduction::                Read this first.
+* General Use::                 Everyday cryptographic functions.
+* Remailer Support::            Interface to secure anonymous remailers.
+* Passphrase Cache::            Letting Mailcrypt remember your passphrase
+for a while.
+* Key Fetching::                Automatically retrieving public keys
+via finger or HTTP.
+* Miscellaneous Configuration::  Random tweakables.
+* Tips::                        Hints and tricks.
+* Limitations::                 Things Mailcrypt does not do.
+* References::                  Pointers to relevant information.
+* Credits::                     Whom to blame.
+* Index::                       Keys, variables, and functions.
+--- The Detailed Node Listing ---
+Introduction
+* Prerequisites::               Complicated stuff you may have to do.
+* Installation::                Simple stuff you probably have to do.
+* Command Overview::            A brief summary of the most common
+commands.
+Installation
+* Hooking into Rmail::
+* Hooking into VM::
+* Hooking into MH-E::
+* Hooking into Gnus::
+General Use
+* Encrypting::                  Encrypting a message to one or more
+recipients.
+* Signing::                     Clearsigning a message.
+* Inserting Keys::              Extracting a key from your public key
+ring and inserting it.
+* Decrypting::                  Decrypting a message to you.
+* Verifying::                   Verifying the signature on a clearsigned
+message.
+* Snarfing Keys::               Finding a key in the current message and
+adding it to your keyring.
+Remailer Support
+* Remailer Introduction::       A little about remailers in general.
+* Remailer Quick Start::        Getting started quickly.
+* Remailer Chains::             Creating custom chains of your very own.
+* Response Blocks::             A way to let people reply to your
+anonymous messages.
+* Pseudonyms::                  Who do you want to be today?
+* Remailing Posts::             Posting to USENET anonymously or
+pseduonymously.
+* Mixmaster Support::           Remailers for the truly paranoid.
+* Remailer Security::           Caveats.
+* Verifiable Pseudonyms::       Giving expression to the voices in your
+head.
+* Remailer Tips::               Free advice.
+Key Fetching
+* Keyring Fetch::               Fetching from one or more other
+keyrings on the local system.
+* Finger Fetch::                Fetching a key through finger.
+* HTTP Fetch::                  Fetching a key off of the Web.
+Miscellaneous Configuration
+* Alternate Keyring::           Specifying a different file to act
+like your public keyring.
+* Comment Field::               Burma
+Shave
+* Mode Line::                   Changing that "MC-w" and "MC-r" stuff
+* Key Bindings::                Which keys cause which actions.
+* Nonstandard Paths::           Useful if your PGP installation is weird.
+References
+* Online Resources::            Recreational reading with a purpose.
+* Key Servers::                 Keepers of the Global Keyring.
+* Mailing List::                Staying informed while pumping the
+authors' egos.
+* Politics::                    Anarcho-foobarism.
+@end menu
+@node Introduction, General Use, Top, Top
+@chapter Introduction
+Mailcrypt is an Emacs Lisp package which provides a simple but powerful
+interface to cryptographic functions for mail and news.  With Mailcrypt,
+encryption becomes a seamlessly integrated part of your mail and news
+handling environment.
+This manual is long because it is complete.  All of the information you
+need to get started is contained in this Introduction alone.
+@menu
+* Prerequisites::               Complicated stuff you may have to do.
+* Installation::                Simple stuff you probably have to do.
+* Command Overview::            A brief summary of the most common
+commands.
+@end menu
+@node Prerequisites, Installation, Introduction, Introduction
+@section Prerequisites
+Mailcrypt requires version 19 of GNU Emacs.  Mailcrypt has been tested
+on a variety of systems under both FSF Emacs and XEmacs.
+Mailcrypt requires Pretty Good (tm) Privacy, usually known as PGP.  This
+document assumes that you have already obtained and installed PGP and
+that you are familiar with its basic functions.  The best way to become
+familiar with these functions is to read the @cite{PGP User's Guide}, at
+least Volume I.
+For more information on obtaining and installing PGP, refer to the MIT
+PGP home page at @file{http://web.mit.edu/network/pgp.html}.
+Although Mailcrypt may be used to process data in arbitrary Emacs
+buffers, it is most useful in conjunction with other Emacs packages for
+handling mail and news.  Mailcrypt has specialized support for Rmail
+(@pxref{Rmail, Rmail, Reading Mail with Rmail, emacs, The GNU Emacs
+Manual}), VM (@pxref{Top, VM, Introduction, vm, The VM User's Manual}),
+MH-E, and Gnus (@pxref{Top, Gnus, Overview, gnus, The Gnus Manual}).
+Information on the general use of these packages is beyond the scope of
+this manual.
+@node Installation, Command Overview, Prerequisites, Introduction
+@section Installation
+If Mailcrypt is not installed on your system, obtain the latest version
+from the Mailcrypt home page at
+@file{http://cag-www.lcs.mit.edu/mailcrypt/} and follow the instructions
+in the file @file{INSTALL}.
+Next, teach your Emacs how and when to load the Mailcrypt functions and
+install the Mailcrypt key bindings.  Almost all Emacs major modes
+(including mail and news handling modes) have corresponding "hook"
+variables which hold functions to be run when the mode is entered.  All
+you have to do is add the Mailcrypt installer functions to the
+appropriate hooks; then the installer functions will add the Mailcrypt
+key bindings when the respective mode is entered.
+Specifically, begin by placing the following lines into your
+@file{.emacs} file (or the system-wide @file{default.el} file):
+@lisp
+(autoload 'mc-install-write-mode "mailcrypt" nil t)
+(autoload 'mc-install-read-mode "mailcrypt" nil t)
+(add-hook 'mail-mode-hook 'mc-install-write-mode)
+@end lisp
+Then add additional lines for your own mail and news packages as
+described below.
+@menu
+* Hooking into Rmail::
+* Hooking into VM::
+* Hooking into MH-E::
+* Hooking into Gnus::
+@end menu
+@node Hooking into Rmail, Hooking into VM, Installation, Installation
+@subsection Hooking into Rmail
+To hook Mailcrypt into Rmail, use the following lines:
+@lisp
+(add-hook 'rmail-mode-hook 'mc-install-read-mode)
+(add-hook 'rmail-summary-mode-hook 'mc-install-read-mode)
+@end lisp
+@node Hooking into VM, Hooking into MH-E, Hooking into Rmail, Installation
+@subsection Hooking into VM
+To hook Mailcrypt into VM, use the following lines:
+@lisp
+(add-hook 'vm-mode-hook 'mc-install-read-mode)
+(add-hook 'vm-summary-mode-hook 'mc-install-read-mode)
+(add-hook 'vm-virtual-mode-hook 'mc-install-read-mode)
+(add-hook 'vm-mail-mode-hook 'mc-install-write-mode)
+@end lisp
+@node Hooking into MH-E, Hooking into Gnus, Hooking into VM, Installation
+@subsection Hooking into MH-E
+To hook Mailcrypt into MH-E, use the following lines:
+@lisp
+(add-hook 'mh-folder-mode-hook 'mc-install-read-mode)
+(add-hook 'mh-letter-mode-hook 'mc-install-write-mode)
+@end lisp
+@node Hooking into Gnus,  , Hooking into MH-E, Installation
+@subsection Hooking into Gnus
+To hook Mailcrypt into Gnus, use the following lines:
+@lisp
+(add-hook 'gnus-summary-mode-hook 'mc-install-read-mode)
+(add-hook 'news-reply-mode-hook 'mc-install-write-mode)
+@end lisp
+@node Command Overview,  , Installation, Introduction
+@section Command Overview
+All Mailcrypt commands are (by default) activated by three-character key
+sequences which begin with @kbd{C-c /}.  The four most common operations
+are:
+@table @emph
+@item Encrypting a Message
+@kbd{C-c / e} encrypts a message using the recipient's (or recipients')
+public key(s).  @xref{Encrypting, , Encrypting a Message}.
+@item Decrypting a Message
+@kbd{C-c / d} decrypts a message using your secret key.
+@xref{Decrypting, , Decrypting a Message}.
+@item Signing a Message
+@kbd{C-c / s} clearsigns a message using your secret key.
+@xref{Signing, , Signing a Message}.
+@item Verifying a Signature
+@kbd{C-c / v} verifies the signature on a clearsigned message using the
+sender's public key.  @xref{Verifying, , Verifying a Signature}.
+@end table
+These functions and others are documented in detail in the following
+chapters.
+Any time you are composing or reading mail or news, you can get a
+summary of the available commands by typing @kbd{C-h m}.  If you are
+running Emacs under X, an even easier way to see the available commands
+is to access the @code{Mailcrypt} pull-down menu.
+@node  General Use, Remailer Support, Introduction, Top
+@chapter General Use
+@findex mc-read-mode
+@findex mc-write-mode
+Mailcrypt works by providing two minor modes for interfacing with
+cryptographic functions: @code{mc-read-mode} and @code{mc-write-mode}.
+@code{mc-read-mode} provides key bindings for processing messages which
+you have received; @code{mc-write-mode} provides key bindings for
+processing messages which you are about to send.  These minor modes will
+indicate when they are active by placing a characteristic string in the
+mode line (@pxref{Mode Line}).  They will also add a @code{Mailcrypt}
+pull-down menu to the menu bar.
+@findex mc-install-read-mode
+@findex mc-install-write-mode
+The normal installation procedure (@pxref{Installation}) will arrange
+for the appropriate mode to be active when you read and compose mail and
+news.  But you may want to use Mailcrypt's functions at other times; to
+do so, you can call @code{mc-install-read-mode} or
+@code{mc-install-write-mode} directly.  For example, if you were editing
+a file in Text mode and wanted to digitally sign it, you would type
+@kbd{M-x mc-install-write-mode}, then @kbd{C-c / s} (@pxref{Signing}).
+Once one of the Mailcrypt modes is active, you can get a summary of the
+available functions by typing @kbd{C-h m} or by examining the
+@code{Mailcrypt} pull-down menu.
+The description of each function below includes which of the modes has a
+binding for that function.
+@menu
+* Encrypting::                  Encrypting a message to one or more
+recipients.
+* Signing::                     Clearsigning a message.
+* Inserting Keys::              Extracting a key from your public key
+ring and inserting it.
+* Decrypting::                  Decrypting a message to you.
+* Verifying::                   Verifying the signature on a clearsigned
+message.
+* Snarfing Keys::               Finding a key in the current message and
+adding it to your keyring.
+@end menu
+@node Encrypting, Signing, General Use, General Use
+@section Encrypting a Message
+@findex mc-encrypt
+@kindex C-c / e
+The function @code{mc-encrypt} will encrypt a message in the current
+buffer.  @code{mc-write-mode} binds this function to @kbd{C-c / e} by
+default.
+When this function is called, Mailcrypt will prompt you for a
+comma-separated list of recipients.  If called from a mail composition
+buffer, the recipient list will default to the Email addresses in the
+@samp{To}, @samp{CC}, and @samp{BCC} lines of the message.
+@vindex mc-encrypt-for-me
+If you want to be able to decrypt the message yourself, you need to add
+yourself to the recipient list.  If you always want to do so, set the
+variable @code{mc-encrypt-for-me} to @code{t}.  (Note that Mailcrypt
+overrides the PGP "encrypttoself" flag; use this variable instead.)
+If you provide an empty recipient list, Mailcrypt will ASCII-armor the
+message without encrypting it.
+@vindex mc-pgp-always-sign
+Once you have edited the recipient list to your satisfaction, type
+@kbd{@key{RET}} to accept it.  You will then be asked whether you want
+to sign the message; answer @kbd{y} or @kbd{n}.  You can avoid this
+question by setting the variable @code{mc-pgp-always-sign}:  A value of
+@code{t} means "yes", a value of @code{'never} means "no".
+If you elect to sign the message, Mailcrypt will prompt you for the
+appropriate passphrase unless it is cached (@pxref{Passphrase Cache}).
+@vindex mc-pre-encryption-hook
+@vindex mc-post-encryption-hook
+Mailcrypt will then pass the message to PGP for processing.  Mailcrypt
+will call the functions listed in @code{mc-pre-encryption-hook} and
+@code{mc-post-encryption-hook} immediately before and after processing,
+respectively.  The encrypted message will then replace the original
+message in the buffer.  You can undo the encryption with the normal
+Emacs undo command @kbd{C-x u} (@pxref{Undo, Emacs Undo, Undoing
+Changes, emacs, The GNU Emacs Manual}).
+If an error occurs, Mailcrypt will display an appropriate diagnostic.
+If you do not have the public key for one of the specified recipients,
+Mailcrypt will offer to try to fetch it for you (@pxref{Key Fetching}).
+@vindex mc-pgp-user-id
+The default key for signing is the first one on the secret key ring
+which matches the string @code{mc-pgp-user-id}; this defaults to
+@code{(user-login-name)}.  Note that this differs from PGP's normal
+default, which is to use the first of @emph{all} of the secret keys.  To
+mimic PGP's behavior, set this variable to @code{""}.
+If you want to use a secret key other than your default for signing the
+message, pass a prefix argument to @code{mc-encrypt}.  (That is, type
+@kbd{C-u C-c / e}.)  Mailcrypt will prompt for a string and will sign with
+the first key on your secret keyring which matches that string.  It will
+be assumed that you want to sign the message, so you will not be
+prompted.
+@node Signing, Inserting Keys, Encrypting, General Use
+@section Signing a Message
+@findex mc-sign
+@kindex C-c / s
+The function @code{mc-sign} will clearsign a message in the current
+buffer.  @code{mc-write-mode} binds this function to @kbd{C-c / s} by
+default.
+When this function is called, Mailcrypt will prompt you for the
+appropriate passphrase unless it is cached (@pxref{Passphrase Cache}).
+@vindex mc-pre-signature-hook
+@vindex mc-post-signature-hook
+Mailcrypt will then pass the message to PGP for processing.  Mailcrypt
+will call the functions listed in @code{mc-pre-signature-hook} and
+@code{mc-post-signature-hook} immediately before and after processing,
+respectively.  The signed message will replace the original message in
+the buffer.  @emph{Do not} edit the message further with the signature
+attached, because the signature would then be incorrect.  If you
+discover you need to edit a message after you have signed it, remove the
+signature first with the normal Emacs undo command @kbd{C-x u}
+(@pxref{Undo, Emacs Undo, Undoing Changes, emacs, The GNU Emacs
+Manual}).
+The variable @code{mc-pgp-user-id} controls which secret key is used for
+signing; it is described in @ref{Encrypting, , Encrypting a Message}.
+To use a different secret key, pass a prefix argument to @code{mc-sign}.
+(That is, type @kbd{C-u C-c / s}.)  Mailcrypt will prompt for a string
+and will sign with the first key on your secret keyring which matches
+that string.
+@node Inserting Keys, Decrypting, Signing, General Use
+@section Inserting a Public Key Block
+@findex mc-insert-public-key
+@kindex C-c / x
+The function @code{mc-insert-public-key} will extract a key from your
+public keyring and insert it into the current buffer.
+@code{mc-write-mode} binds this function to @kbd{C-c / x} by default.
+This function is useful for sending your public key to someone else or
+for uploading it to the key servers (@pxref{Key Servers}).  The inserted
+key will be the first one on your public key ring which matches the
+string @code{mc-pgp-user-id} (@pxref{Encrypting, , Encrypting a
+Message}).
+You may want to insert a different public key instead; for example, you
+may have signed someone's key and want to send it back to them.  To do
+so, pass a prefix argument to @code{mc-insert-public-key}.  (That is,
+type @kbd{C-u C-c / x}.)  You will be prompted for a string; the first key
+on your public key ring which matches that string will be inserted.
+@node Decrypting, Verifying, Inserting Keys, General Use
+@section Decrypting a message
+@findex mc-decrypt
+@kindex C-c / d
+The function @code{mc-decrypt} will decrypt a message in the current
+buffer.  @code{mc-read-mode} binds this function to @kbd{C-c / d} by
+default.
+When this function is called, Mailcrypt will prompt you for the
+appropriate passphrase unless it is cached (@pxref{Passphrase Cache}).
+The encrypted message will then be passed to PGP for processing.  If you
+are not in a mail buffer, the decrypted message will replace the
+encrypted form.  If you are in a mail buffer, you will be prompted
+whether to do the replacement.
+If you answer @kbd{n}, you will be placed in a new mail reading buffer
+to view the decrypted message.  This new mail reading buffer will have
+no corresponding disk file; its purpose is to provide you with all of
+your usual reply and citation functions without requiring you to save
+the message in decrypted form.  Type @kbd{q} to kill this buffer.
+@vindex mc-always-replace
+You can avoid the question of whether to replace the encrypted message
+by setting the variable @code{mc-always-replace}.  A value of @code{t}
+means "yes"; a value of @code{'never} means "no".
+If the encrypted message is also signed, PGP will attempt to verify the
+signature.  If the verification fails because you lack the necessary
+public key, Mailcrypt will offer to fetch it for you (@pxref{Key
+Fetching}).
+Look in the @code{*MailCrypt*} buffer to see the result of the signature
+verification.
+@node Verifying, Snarfing Keys, Decrypting, General Use
+@section Verifying a Signature
+@findex mc-verify
+@kindex C-c / v
+The function @code{mc-verify} will verify the cleartext signature on a
+message in the current buffer.  @code{mc-read-mode} binds this function
+to @kbd{C-c / v} by default.
+When this function is called, Mailcrypt will pass the message to PGP for
+processing and report whether or not the signature verified.
+If the signature failed to verify because you lack the necessary public
+key, Mailcrypt will offer to fetch it for you (@pxref{Key Fetching}).
+@node Snarfing Keys,  , Verifying, General Use
+@section Snarfing a Key
+@findex mc-snarf
+@kindex C-c / a
+The function @code{mc-snarf} will add to your keyring any keys in the
+current buffer.  @code{mc-read-mode} binds this function to @kbd{C-c / a}
+by default.
+This function is useful when someone sends you a public key in an Email
+message.
+@node Remailer Support, Passphrase Cache, General Use, Top
+@chapter Remailer Support
+This is a long chapter describing an advanced feature; you
+may want to skip it on first reading.
+@menu
+* Remailer Introduction::       A little about remailers in general.
+* Remailer Quick Start::        Getting started quickly.
+* Remailer Chains::             Creating custom chains of your very own.
+* Response Blocks::             A way to let people reply to your
+anonymous messages.
+* Pseudonyms::                  Who do you want to be today?
+* Remailing Posts::             Posting to USENET anonymously or
+pseduonymously.
+* Mixmaster Support::           Remailers for the truly paranoid.
+* Remailer Security::           Caveats.
+* Verifiable Pseudonyms::       Giving expression to the voices in your
+head.
+* Remailer Tips::               Free advice.
+@end menu
+@node Remailer Introduction, Remailer Quick Start, Remailer Support, Remailer Support
+@section Remailer Introduction
+There are several anonymous remailer services running on the Internet.
+These are programs that accept mail, strip off information that would
+identify the origin of the message, and forward the mail to the
+designated recipient.  This simple scheme alone, however, is insecure if
+the anonymous remailer becomes compromised (or if the remailer was set
+up by an untrustworthy party in the first place).  Whoever controls the
+remailer will have access to the identities of senders and recipients.
+One solution to this is to use @emph{chains} of remailers that send
+encrypted messages.  For example, suppose Bill wishes to send a message
+to Louis using a chain of remailers A, B, and C.  He writes the message
+(possibly encrypting it for Louis), then encrypts the result (including
+the fact that Louis is the recipient) using a public key supplied by
+remailer C.  Then he encrypts this result using a public key supplied by
+remailer B.  Then he encrypts this result using a public key supplied by
+A and sends the message to A.
+When A receives the message, it decrypts the message with its key to
+produce something encrypted for B, learns that the next remailer in the
+chain is B, strips off the information that the message came from Bill,
+and sends the message on to B.  B then decrypts, learns that the next
+remailer in the chain is C, strips off the information that the message
+came from A, and sends the result to C.  C then decrypts, learns that
+the destination is Louis, strips off the information that the message
+came from B, and sends the result to Louis.  With this arrangement, only
+A knows that the original message came from Bill, and only C knows that
+the intended recipient is Louis.  In general, the sender and recipient
+can both be known only to someone who has compromised all remailers in
+the chain.
+If Bill wishes, he can include an encrypted "response block" in his
+message to Louis, which defines a remailer chain that Louis can use to
+reply to Bill.  Louis can use this chain without knowing who Bill is --
+only the last remailer in the chain need know the final recipient.  Bill
+can also establish a @emph{pseudonym} for use in signing his anonymous
+messages.
+Mailcrypt includes facilities for sending messages via remailers, for
+defining chains of remailers, for generating response blocks, and for
+using pseudonyms.
+@node Remailer Quick Start, Remailer Chains, Remailer Introduction, Remailer Support
+@section Remailer Quick Start
+To use Mailcrypt's remailing facilities, you need to configure them
+first.  Begin with the following steps:
+@enumerate
+@item
+Do @samp{finger remailer-list@@kiwi.cs.berkeley.edu > ~/.remailers}.
+This will create a Levien-format list of remailers in the file
+@file{.remailers} in your home directory.  Mailcrypt will parse this the
+first time you access a remailer function.
+@item
+Look over the @file{.remailers} file and find the ones you want to use.
+@item
+Add their PGP public keys to your keyring.  You can @code{finger
+pgpkeys@@kiwi.cs.berkeley.edu} for a list of remailer public keys.  Note
+that Mailcrypt @emph{requires} that you have the public keys of all the
+remailers you want to use, and therefore that the remailers support PGP
+encryption.
+@end enumerate
+@quotation
+@emph{Note:} These steps need only be done once, although repeating them
+from time to time is probably a good idea, since remailers come and go.
+@end quotation
+Now test the remailer functions.  First compose an outgoing Email
+message (using @kbd{C-x m}, for example) addressed to yourself.  Type
+@kbd{C-c / r}.  Choose a remailer; use @kbd{@key{TAB}} to get completion
+on its name.  The buffer will be rewritten for anonymous mailing through
+that remailer.
+@node Remailer Chains, Response Blocks, Remailer Quick Start, Remailer Support
+@section Remailer Chains
+@findex mc-remailer-encrypt-for-chain
+@kindex C-c / r
+@code{mc-write-mode} binds the function
+@code{mc-remailer-encrypt-for-chain} to the key @kbd{C-c / r}.  This
+function rewrites the message for a remailer or chain.  The resulting
+buffer is just a new Email message, so it can itself be rewritten for
+another remailer; this is one way to manually construct a remailer
+chain.
+Mailcrypt also has powerful facilities for defining automatic chains.
+We will start with an example.  Suppose you have put the following into
+your @file{.emacs} file:
+@vindex mc-remailer-user-chains
+@lisp
+(setq mc-remailer-user-chains
+'(("Foo" "alumni" "robo")
+("Bar" (shuffle-vector ["replay" "flame" "spook"]))
+("Baz" "Foo" "Bar" "rahul" "Bar")
+("Quux" 4)))
+@end lisp
+This code defines four chains.  The first is named "Foo" and consists of
+"alumni" and "robo", in that order.  The second is named "Bar" and
+consists of "replay", "flame", and "spook" in some random order (a
+different order will be chosen each time the chain is used).  The third
+is named "Baz" and consists of 9 remailers: The two from "Foo", followed
+by a permutation of the three from "Bar", followed by "rahul", followed
+by another permutation of the three from "Bar".  Finally, the fourth is
+named "Quux" and consists of a random permutation of the four best
+remailers as ordered in the @file{~/.remailers} file.
+Now whenever you are prompted for a "remailer or chain", the chains
+"Foo", "Bar", "Baz", and "Quux" will be available, including
+@kbd{@key{TAB}} completion on their names.  By capitalizing their names,
+you guarantee they will show up near the top of the completion list if
+you type @kbd{@key{TAB}} on an empty input.
+Now for the gritty details.  @code{mc-remailer-user-chains} is a list of
+chain definitions.  A chain definition is a list whose first element is
+the name (a string) and whose remaining elements form a @dfn{remailer
+list}.  Each element of a remailer list is one of the following:
+@enumerate
+@item
+A raw remailer structure.  This is the base case, but you will probably
+never want nor need to deal with these directly.
+@item
+A string naming another remailer chain to be spliced in at this point.
+@item
+A positive integer N representing a chain to be spliced in at this point
+and consisting of a random permutation of the top N remailers as ordered
+in the @file{~/.remailers} file.
+@item
+An arbitrary Emacs Lisp form, which should return another remailer
+list which will be spliced in at this point and recursively
+evaluated.  Mmmm, Lisp.
+@end enumerate
+So, in the example "Bar" above, @code{shuffle-vector} is actually a Lisp
+primitive which returns a random permutation of the argument vector.
+(Which brings up a side note: A remailer list can be a vector instead of
+a list if you like.)
+So where do the definitions for "replay" etc. come from?
+@vindex mc-remailer-internal-chains
+There is another variable, @code{mc-remailer-internal-chains}, which has
+the same format as @code{mc-remailer-user-chains}.  In fact, the
+concatenation of the two is always used internally when resolving chains
+by name.  The "internal chains" are normally generated automatically
+from a Levien-format remailer list, which lives in @file{~/.remailers}
+by default and is parsed at startup time.  The parser creates several
+chains, each containing a single remailer, and names each chain after
+the respective remailer.
+Thus "replay" (for example) is actually the name of a @emph{chain} whose
+single element is the remailer at <remailer@@replay.com>.  So "replay"
+is a valid name of a chain to include in the definition of another
+chain, as was done above in the definition of "Bar".
+@node Response Blocks, Pseudonyms, Remailer Chains, Remailer Support
+@section Response Blocks
+@kindex C-c / b
+Mailcrypt can generate a response block for you.  Just type @kbd{C-c / b}
+in an outgoing mail buffer.  That will prompt you for a chain to use,
+and will insert the response block at point.  Note that you can use any
+chain you want for your response block; it need not be related to the
+chain you (later) use to remail the message.
+If instead you type @kbd{C-u C-c / b}, you will be dropped into a
+recursive edit of the innermost part of the response block.  This text
+is what you will see at the top of the message when the response block
+is used.  This text is the only way to identify the response block,
+since it will be used to mail you through anonymous remailers.
+You probably won't need to use the @kbd{C-u} feature, since by default
+the response block contains the date, @samp{To} field, and @samp{From}
+field of the message you are composing.  However, if you want your
+response block to point to a USENET newsgroup instead of your Email
+address, you may edit the innermost part of the response block to have a
+@samp{Newsgroups} line instead of a @samp{To} line.
+Inserting a response block also updates the @samp{Reply-to} hashmark
+header field.  So, when your recipient replies to your message, the
+reply will automatically be addressed properly.  This only works if the
+last remailer in the chain used to encrypt the @emph{message} supports
+hashmarks (the response block chain doesn't matter).  If the last
+remailer does not support hashmarks, Mailcrypt will generate an error
+when you try to use the chain.
+Note that you should insert your response block before you encrypt the
+message for remailing.  Also, see @ref{Remailer Security}.
+@node Pseudonyms, Remailing Posts, Response Blocks, Remailer Support
+@section Pseudonyms
+@kindex C-c / p
+Mailcrypt supports pseudonyms.  Type @kbd{C-c / p} in an outgoing message
+buffer and you will be prompted for a pseudonym to use.  Your pseudonym
+will show up in the @samp{From} line that the recipient sees.  Your
+pseudonym may either be a complete @samp{From} line (including an Email
+address), or just a full name (with no Email address).  In the latter
+case, the Email address will automatically be set to <x@@x.x>, an invalid
+address designed to prevent sendmail from going rewrite-happy.
+If you have one or more pseudonyms which you normally use, and you
+aren't afraid of revealing them if your account is compromised, you can
+set up a default list of pseudonyms with lines like the following in
+your @file{.emacs} file:
+@vindex mc-remailer-pseudonyms
+@lisp
+(setq mc-remailer-pseudonyms
+'("Elvis Presley" "Vanna White" "Charles Manson"))
+@end lisp
+Then those names will be available for completion when you are
+prompted for your pseudonym.
+You should insert your pseudonym before you insert a response block, so
+that the response block will contain the @samp{From} line as well as the
+@samp{To} line.  That way you can tell who you were pretending to be
+when you get a reply to your message.
+Note: Many remailers do not support pseudonyms.  In addition, the Levien
+format does not (yet) indicate which do and which do not, so Mailcrypt
+can't warn you when your pseudonym isn't going to work.  The only way to
+be sure is to send yourself a test message, and to try different
+remailers until you find one or more which work.  On the bright side,
+only the last remailer in the chain needs to provide such support; none
+of the others matter.
+@node Remailing Posts, Mixmaster Support, Pseudonyms, Remailer Support
+@section Remailing Posts
+Mailcrypt knows how to rewrite USENET posts for anonymous or
+pseudonymous remailing.  Just compose your post or followup normally,
+and use @kbd{C-c / r} to rewrite it for a remailer chain.  You don't
+even need to start your newsreader to make a post; you can just compose
+a message in mail mode and replace the @samp{To} line with a
+@samp{Newsgroups} line before doing @kbd{C-c / r}.
+@vindex mc-remailer-preserved-headers
+Mailcrypt will generate an error if the last remailer in the chain does
+not have both the @code{post} and @code{hash} (hashmarks) properties.
+The hashmarks are used to preserve @samp{References} and similar
+headers, so your anonymous or pseudonymous followups will thread
+properly.  The variable @code{mc-remailer-preserved-headers} controls
+which headers are preserved when rewriting a message, but you should not
+need to change it since the default value is reasonable.
+Before rewriting, you can use @kbd{C-c / p} to insert your pseudonym,
+and @kbd{C-c / b} to insert your response block, just like when
+composing mail.  In this case, the response block will include the
+@samp{From} line and the @samp{Newsgroups} line (which is the news
+analogue to the @samp{To} line).
+@node Mixmaster Support, Remailer Security, Remailing Posts, Remailer Support
+@section Mixmaster Support
+@dfn{Mixmaster} is a new kind of remailer which provides excellent
+security against traffic analysis and replay attacks.  (For more
+information on these attacks and Mixmaster, see Lance Cottrell's home
+page at @file{http://www.obscura.com/~loki/}.
+If you do not use Mixmaster, you may skip this section entirely;
+Mailcrypt's default configuration treats Mixmaster as if it did not
+exist.
+If you have the Mixmaster executable installed, you can tell Mailcrypt
+to use it by placing lines like the following into your @file{.emacs}
+file:
+@vindex mc-mixmaster-path
+@vindex mc-mixmaster-list-path
+@lisp
+(setq mc-mixmaster-path "mixmaster")
+(setq mc-mixmaster-list-path "/foo/bar/baz/type2.list")
+@end lisp
+@code{mc-mixmaster-path} is a string representing the Mixmaster
+executable.  @code{mc-mixmaster-list-path} is the complete path to the
+@code{type2.list} file.
+Once these variables are defined, Mailcrypt will automatically try to
+use the Mixmaster executable whenever possible.  Specifically, when you
+rewrite a message for a chain, Mailcrypt will find maximal length
+sub-chains which have the @code{mix} property and will use the Mixmaster
+executable to rewrite for those sub-chains.
+This allows arbitrary intermingling of Mixmaster and normal (also called
+@dfn{Type 1}) remailers, but you should note that this is @emph{not
+recommended}.  The recommended procedure is to have a single Mixmaster
+sub-chain which is most or all of the whole chain.
+There are advantages and disadvantages to having the Mixmaster sub-chain
+at the end of the whole chain.  The primary advantage is that Mixmaster
+remailers support multiple recipients.  The primary disadvantages are
+that they do not support pseudonyms nor posting.
+So here, as always, it is the last element of the chain which needs to
+support the special features you want.  In general, the remaining
+elements do not matter, and the superior security of Mixmaster remailers
+is a good argument for using them for the bulk of your chains.
+@findex mc-demix
+Mixmaster remailers also have a "Type 1 compatibility mode" which you
+might want to invoke to use a pseudonym or make a post.  You can do this
+with the function @code{mc-demix}.  Here is an example of its use:
+@lisp
+(setq mc-remailer-user-chains
+'(("Foo" "vishnu" "spook")
+("Bar" "Foo" (mc-demix "replay"))))
+@end lisp
+This makes "Bar" a chain of three remailers, and guarantees that the
+last one ("replay") will be used in compatibility mode.
+Note that Mixmaster remailers cannot be used for response blocks.
+Mailcrypt will ignore the @code{mix} property when generating a response
+block.
+@node Remailer Security, Verifiable Pseudonyms, Mixmaster Support, Remailer Support
+@section Remailer Security
+Keep in mind that there is only one person fully qualified to protect
+your privacy: @emph{you}.  You are responsible for obtaining a list of
+remailers and their public keys; you are responsible for choosing which
+of them to use and in what order.  There are public lists of remailers
+and keys (the Quick Start section above relies on them), but you pay for
+the convenience by putting your trust in a single source.  This is one
+reason Mailcrypt does not access these public lists automatically; you
+need to get into the habit of watching what goes on behind the scenes.
+You should also try to learn something about the remailers themselves,
+since you are relying on them to help protect your privacy.
+How many remailers should you include in your chain, and how should
+you choose them?  That depends on whom you perceive as a threat.  If
+the threat is your ex-spouse or your boss, even a single remailer is
+probably adequate (more won't hurt, but will cost in latency).  If the
+threat is the Church of Scientology, you probably want to use a fair
+number of remailers across multiple continents.  If the threat is a
+major world government, well, best of luck to you.
+Also, there is a huge difference between chains suitable for regular
+messages and chains suitable for response blocks.  Some remailers don't
+even keep mail logs (at least, their operators claim they do not), so it
+may be literally impossible to trace a message back to you after the
+fact if you chain it through enough remailers.  Response blocks, on the
+other hand, have your identity buried in there @emph{somewhere}.  In
+principle, at least, it is possible to compromise the keys of all the
+remailers in the chain and decrypt the response block.  So you should
+either use very long and strong chains for your response blocks, avoid
+using response blocks at all, or only use response blocks which
+themselves ultimately point to a newsgroup.
+@node Verifiable Pseudonyms, Remailer Tips, Remailer Security, Remailer Support
+@section Verifiable Pseudonyms
+Here is a plausible sequence of operations when using the remailer
+support in Mailcrypt:
+@enumerate
+@item
+You create a public/private PGP key pair.  You give it a User ID which
+is your pseudonym.  You upload the public key to the key servers or
+otherwise distribute it.  (Be aware that anyone who compromises your
+account can read the IDs on your secret keyring, thus discovering your
+verifiable pseudonyms.)
+@item
+You compose an Email message, Email reply, news post, or news followup.
+@item
+You insert your pseudonym with @kbd{C-c / p}.
+@item
+(Optional) You insert your response block with @kbd{C-c / b}.
+@item
+You type @kbd{C-c / s} to sign the message.  The @code{mc-sign} function
+understands pseudonyms.
+@item
+You type @kbd{C-c / r} to rewrite the message for remailing.  (Or use
+@kbd{C-u C-c / r} to view each step of the rewriting as it happens.)
+@item
+You type @kbd{C-c C-c} to send the message.
+@end enumerate
+Now the recipient(s), reading your message through mail or news, can
+verify your pseudonymous signature; thus you have started to create a
+verifiable pseudonymous identity.  If you use it consistently, it will
+develop a reputation of its own.  With Mailcrypt, using a pseudonym is
+almost as easy as using your real name (and your followups in news
+will even thread properly).  Welcome to the new age of letters@dots{}
+@node Remailer Tips,  , Verifiable Pseudonyms, Remailer Support
+@section Remailer Tips
+This is a collection of tips for using Mailcrypt's remailer support.
+@itemize @bullet
+@item
+@vindex mc-levien-file-name
+Read and understand the @file{.remailers} file.  If the service at
+kiwi.cs.berkeley.edu is gone by the time you read this, track down a
+comparable service elsewhere.  (Ask around in
+@file{news:alt.privacy.anon-server} or, as a last resort,
+@file{news:alt.security.pgp}.)  Check the documentation (@kbd{C-h v})
+for the variable @code{mc-levien-file-name} for a description of Levien
+format.
+@item
+The relevant remailer properties are @code{pgp} (required), @code{hash}
+(required if you use hashmark headers), and @code{post} (required for
+posting to USENET).  Remailers which do not support PGP won't even show
+up in the completion list.
+@item
+The only remailer which needs special properties (e.g., posting,
+hashmarks, pseudonym support) is the last one in a chain.  Any remailer
+can be used at the beginning or in the middle.  So if you find a few
+remailers which support the feature(s) you require, and you always use
+them at the end of your chains, then you can be confident that even the
+longest chains will work.
+@item
+@findex mc-reread-levien-file
+If you update your @file{~/.remailers} file, you can reread it with
+@kbd{M-x mc-reread-levien-file}.
+@item
+Remember the natural order of operations.  First you compose your
+message.  Then you insert your pseudonym with @kbd{C-c / p}.  Then you
+insert your response block with @kbd{C-c / b}.  Then you sign (@kbd{C-c /
+s}) or sign and encrypt (@kbd{C-c / e}) the message.  Then you rewrite it
+for a remailer or chain (@kbd{C-c / r}).  Then you send it.  All but the
+first and last two of these are optional.  (Well, strictly speaking,
+they are all optional, but you get the idea.)
+@item
+Find and read some of the excellent remailer documentation available on
+the Internet.  For some good starting points, see @ref{References}.
+@end itemize
+@node Passphrase Cache, Key Fetching, Remailer Support, Top
+@chapter Passphrase Cache
+@vindex mc-passwd-timeout
+Mailcrypt can remember your passphrase so that you need not type it
+repeatedly.  It will also "forget" your passphrase if it has not been
+used in a while, thus trading some security for some convenience.  You
+can tune this tradeoff with the variable @code{mc-passwd-timeout}, which
+is a duration in seconds from the last time the passphrase was used
+until Mailcrypt will forget it.  The default value is 60 seconds.
+So, for example, to make Mailcrypt remember your passphrase for 10
+minutes after each use, you would use the following line in your
+@file{.emacs} file:
+@lisp
+(setq mc-passwd-timeout 600)
+@end lisp
+A value of @code{nil} or 0 will disable passphrase caching completely.
+This provides some increase in security, but be aware that you are
+already playing a dangerous game by typing your passphrase at a Lisp
+interpreter.
+Mailcrypt understands multiple secret keys with distinct passphrases.
+@findex mc-deactivate-passwd
+@kindex C-c / f
+To manually force Mailcrypt to forget your passphrase(s), use the
+function @code{mc-deactivate-passwd}.  Both @code{mc-read-mode} and
+@code{mc-write-mode} bind this function to @kbd{C-c / f} by default.
+@quotation
+@strong{Warning:} Although Mailcrypt takes pains to overwrite your
+passphrase when "forgetting", it cannot prevent the Emacs garbage
+collector from possibly leaving copies elsewhere in memory.  Also, your
+last 100 keystrokes can always be viewed with the function
+@code{view-lossage}, normally bound to @kbd{C-h l}.  So be sure to type
+at least 100 characters after typing your passphrase if you plan to
+leave your terminal unattended.
+@end quotation
+@node Key Fetching, Miscellaneous Configuration, Passphrase Cache, Top
+@chapter Key Fetching
+@findex mc-pgp-fetch-key
+@kindex C-c / k
+Mailcrypt knows how to fetch PGP public keys from the key servers
+(@pxref{Key Servers}).  The function @code{mc-pgp-fetch-key} is bound by
+default to @kbd{C-c / k} in both @code{mc-read-mode} and
+@code{mc-write-mode}.  Additionally, @code{mc-encrypt},
+@code{mc-decrypt}, and @code{mc-verify} will offer to call this function
+to automatically fetch a desired key.  If you call it manually, it will
+prompt you for the User ID of the key to fetch.
+@vindex mc-pgp-fetch-methods
+The variable @code{mc-pgp-fetch-methods} is a list of ways to attempt to
+fetch a key.  (More precisely, it is a list of functions to be called,
+each of which will attempt to fetch the key.)  The methods will be tried
+in the order listed.  The default list is:
+@lisp
+'(mc-pgp-fetch-from-keyrings
+mc-pgp-fetch-from-finger
+mc-pgp-fetch-from-http)
+@end lisp
+For a description of these functions, see the following sections.
+If you are not directly on the Internet, you probably want to obtain a
+copy of the global public key ring from the keyservers, install it
+somewhere under the name @file{public-keys.pgp}, and do:
+@lisp
+(setq mc-pgp-fetch-methods '(mc-pgp-fetch-from-keyrings))
+(setq mc-pgp-fetch-keyring-list '("/blah/blah/blah/public-keys.pgp"))
+@end lisp
+This will allow you to fetch keys from your local copy of the global key
+ring instead of sending requests to the key servers directly
+(@pxref{Keyring Fetch}).  Alternately, if your organization has a proxy
+HTTP server, you can configure Mailcrypt to use that.  See @ref{HTTP
+Fetch}.
+If the key is found, you will be shown the result of running PGP on it
+locally.  This allows you to inspect the signatures on the key
+@emph{relative to your own keyring} before you consent to having it
+added.  @strong{Inspect the signatures carefully!}  Key distribution is
+often the Achilles' heel of public key protocols.  If you blindly use
+keys obtained from the key servers, you are asking for trouble.
+All of the methods use @code{mc-pgp-fetch-timeout} as a timeout in
+seconds; the default value is 30.
+@menu
+* Keyring Fetch::               Fetching from one or more other
+keyrings on the local system.
+* Finger Fetch::                Fetching a key through finger.
+* HTTP Fetch::                  Fetching a key off of the Web.
+@end menu
+@node Keyring Fetch, Finger Fetch, Key Fetching, Key Fetching
+@section Keyring Fetch
+@findex mc-pgp-fetch-from-keyrings
+The function @code{mc-pgp-fetch-from-keyrings} will attempt to fetch a
+key from a set of keyrings on the locally accessible filesystem.  This
+is useful if your organization maintains a large common public keyring
+whose entire contents you do not wish to duplicate on your own ring.  It
+is also useful if you download a copy of the global public ring from the
+key servers (@pxref{Key Servers}).
+@vindex mc-pgp-fetch-keyring-list
+The variable @code{mc-pgp-fetch-keyring-list} controls this behavior.
+It is a list of file names of public keyrings which this function will
+search, in order, when seeking a key.  The default value is @code{nil},
+meaning this search will always fail.
+@node Finger Fetch, HTTP Fetch, Keyring Fetch, Key Fetching
+@section Finger Fetch
+@findex mc-pgp-fetch-from-finger
+The function @code{mc-pgp-fetch-from-finger} will attempt to fetch a key
+by fingering an address and parsing the output for a PGP public key
+block.
+@node  HTTP Fetch,  , Finger Fetch, Key Fetching
+@section HTTP Fetch
+@findex mc-pgp-fetch-from-http
+The function @code{mc-pgp-fetch-from-http} will attempt to fetch a key
+by connecting to a key server (@pxref{Key Servers}) which has a World
+Wide Web interface.
+@vindex mc-pgp-keyserver-address
+@vindex mc-pgp-keyserver-port
+@vindex mc-pgp-keyserver-url-template
+The variables @code{mc-pgp-keyserver-address},
+@code{mc-pgp-keyserver-port}, and @code{mc-pgp-keyserver-url-template}
+control the fetching process.  The default is to use Brian LaMacchia's
+key server at MIT.  If this default should stop working, or if you want
+to help with network congestion and machine load, you can choose a
+different server.  As of this writing, any of the following sequences of
+Emacs Lisp in your @file{.emacs} file will work; choose one:
+@lisp
+;; Key server at MIT (Massachusetts, USA)
+;; This is the default; these lines are only for reference
+;(setq mc-pgp-keyserver-address "pgp.ai.mit.edu")
+;(setq mc-pgp-keyserver-port 80)
+;(setq mc-pgp-keyserver-url-template
+;      "/htbin/pks-extract-key.pl?op=get&search=%s")
+@end lisp
+@lisp
+;; Key server at UPC (Barcelona, Spain)
+(setq mc-pgp-keyserver-address "goliat.upc.es")
+(setq mc-pgp-keyserver-port 80)
+(setq mc-pgp-keyserver-url-template
+"/cgi-bin/pks-extract-key.pl?op=get&search=%s")
+@end lisp
+@lisp
+;; Key server at Cambridge University (Cambridge, England)
+(setq mc-pgp-keyserver-address "www.cl.cam.ac.uk")
+(setq mc-pgp-keyserver-port 80)
+(setq mc-pgp-keyserver-url-template
+"/cgi-bin/pks-extract-key.pl?op=get&search=%s")
+@end lisp
+@lisp
+;; Key server at UIT (Tromso, Norway)
+(setq mc-pgp-keyserver-address "www.service.uit.no")
+(setq mc-pgp-keyserver-port 80)
+(setq mc-pgp-keyserver-url-template
+"/cgi-bin/pks-extract-key.pl?op=get&search=%s")
+@end lisp
+@lisp
+;; Key server at CMU (Pennsylvania, USA)
+(setq mc-pgp-keyserver-address "gs211.sp.cs.cmu.edu")
+(setq mc-pgp-keyserver-port 80)
+(setq mc-pgp-keyserver-url-template "/cgi-bin/pgp-key?pgpid=%s")
+@end lisp
+If your organization has a firewall, you might not be able to access the
+World Wide Web directly.  Your organization may have a proxy HTTP server
+set up, however.  In that case, you should place code like the following
+in your @file{.emacs} file.  You can use any of the above key servers
+instead of the one at MIT, of course.
+@lisp
+;; Mailcrypt configuration for accessing key server through HTTP proxy
+(setq mc-pgp-keyserver-address "your.proxy.com")
+(setq mc-pgp-keyserver-port 13013)  ; Your proxy's port
+(setq mc-pgp-keyserver-url-template
+"http://pgp.ai.mit.edu/htbin/pks-extract-key.pl?op=get&search=%s")
+@end lisp
+Note that fetching from a key server can be somewhat slow, so be
+patient.  (At least it beats the tar out of the Email interface.)
+@node Miscellaneous Configuration, Tips, Key Fetching, Top
+@chapter Miscellaneous Configuration
+This chapter documents some additional Mailcrypt configuration options
+which could not be naturally described elsewhere.
+@menu
+* Alternate Keyring::           Specifying a different file to act
+like your public keyring.
+* Comment Field::               Burma
+Shave
+* Mode Line::                   Changing that "MC-w" and "MC-r" stuff
+* Key Bindings::                Which keys cause which actions.
+* Nonstandard Paths::           Useful if your PGP installation is weird.
+@end menu
+@node Alternate Keyring, Comment Field, Miscellaneous Configuration, Miscellaneous Configuration
+@section Alternate Keyring
+By default, Mailcrypt will use the same public keyring that PGP would
+use if executed from the shell.
+@vindex mc-pgp-alternate-keyring
+You can cause Mailcrypt to use a specific public keyring by setting the
+variable @code{mc-pgp-alternate-keyring}.  If this variable is set,
+Mailcrypt will use that keyring for all functions which would otherwise
+have used the default.  This includes adding keys, extracting keys,
+verifying signatures, and encrypting messages.
+This feature might be useful if you maintain multiple keyrings; you can
+switch between them by setting this variable.  Depending on your tastes,
+you might want to configure fetching from a keyring as well
+(@pxref{Keyring Fetch}).
+@node Comment Field, Mode Line, Alternate Keyring, Miscellaneous Configuration
+@section Comment Field
+By default, Mailcrypt will supply a "comment" option to PGP, resulting
+in output which looks something like this:
+@example
+----- BEGIN PGP FOOBAR -----
+Version: 2.6.3
+Comment: Processed by Mailcrypt @value{VERSION}, an Emacs/PGP interface
+@dots{}
+----- END PGP FOOBAR -----
+@end example
+@vindex mc-pgp-comment
+To change the comment to one of your own, set the variable
+@code{mc-pgp-comment}.  Set it to @code{nil} to use PGP's default, which
+is probably either no comment or something defined in @file{config.txt}.
+@node Mode Line, Key Bindings, Comment Field, Miscellaneous Configuration
+@section Mode Line
+@code{mc-read-mode} and @code{mc-write-mode} will each indicate they are
+active by placing the string @samp{MC-r} or @samp{MC-w} in the mode
+line, respectively.
+@vindex mc-read-mode-string
+@vindex mc-write-mode-string
+You can change these strings by setting the variables
+@code{mc-read-mode-string} and @code{mc-write-mode-string}.  So, for
+example, to get rid of the mode indicators entirely, you might put the
+following lines into your @file{.emacs} file:
+@lisp
+(setq mc-read-mode-string "")
+(setq mc-write-mode-string "")
+@end lisp
+@node Key Bindings, Nonstandard Paths, Mode Line, Miscellaneous Configuration
+@section Key Bindings
+@vindex mc-read-mode-map
+@vindex mc-write-mode-map
+The Mailcrypt key bindings are defined by the keymaps
+@code{mc-read-mode-map} and @code{mc-write-mode-map}.  To change the key
+bindings, you just need to set these variables in your @file{.emacs}
+file.
+For example, if you wanted @kbd{C-c C-m} to be the Mailcrypt prefix
+(instead of @kbd{C-c /}) in @code{mc-read-mode}, you would put the
+following code in your @file{.emacs} file:
+@lisp
+(setq mc-read-mode-map (make-sparse-keymap))
+(define-key mc-read-mode-map "\C-c\C-mf" 'mc-deactivate-passwd)
+(define-key mc-read-mode-map "\C-c\C-md" 'mc-decrypt)
+(define-key mc-read-mode-map "\C-c\C-mv" 'mc-verify)
+(define-key mc-read-mode-map "\C-c\C-ma" 'mc-snarf)
+(define-key mc-read-mode-map "\C-c\C-mk" 'mc-pgp-fetch-key)
+@end lisp
+For more information on Emacs key bindings, see @ref{Key Bindings, ,
+Customizing Key Bindings, emacs, The GNU Emacs Manual}.
+@node Nonstandard Paths,  , Key Bindings, Miscellaneous Configuration
+@section Nonstandard Paths
+The information in this section should be unnecessary, but is provided
+"just in case".
+@vindex mc-pgp-path
+Mailcrypt will look for the PGP executable in your standard search path
+under the name @file{pgp}.  To use a different name (or to provide a
+complete path), set the variable @code{mc-pgp-path}.
+In order to keep your identities straight, Mailcrypt needs to know where
+your secret keyring resides.
+Mailcrypt figures this out heuristically by assuming that the file
+@file{secring.pgp} is in the same directory as your public key ring.  It
+determines the location of the latter by doing a dry run of PGP with
+@samp{+verbose=1} and parsing the output.
+@vindex mc-pgp-keydir
+If this heuristic is failing for you, you can manually tell Mailcrypt
+where your secret key ring is by setting the variable
+@code{mc-pgp-keydir}, like this:
+@lisp
+(setq mc-pgp-keydir "/users/patl/.pgp/")
+@end lisp
+Note that the trailing slash is @emph{required}.
+If the heuristic fails, please report it as a bug (@pxref{Credits}).
+Note that if you have changed the default location of your secret
+keyring, Mailcrypt will be unable to locate it.  You can work around
+this by either setting @code{mc-pgp-keydir}, or by making a symbolic
+link to your secret keyring from @file{secring.pgp} in your default
+public keyring directory.
+@node Tips, Limitations, Miscellaneous Configuration, Top
+@chapter Tips
+Here are some random tips.
+@itemize @bullet
+@item
+PGP provides quite good security when used correctly.  You are far more
+likely to use it correctly if you have read the directions.  Read the
+@cite{PGP User's Guide}!
+@item
+60 seconds is a relatively safe but somewhat inconvenient value for
+@code{mc-passwd-timeout}.  If your paranoia permits, consider increasing
+it to five or ten minutes (@pxref{Passphrase Cache}).
+@item
+If Mailcrypt ever does something you wish it had not, @emph{DON'T
+PANIC}.  Just use the normal Emacs undo command, @kbd{M-x undo} or
+@kbd{C-x u}, to restore your buffer (@pxref{Undo, Emacs Undo, Undoing
+Changes, emacs, The GNU Emacs Manual}).  Mailcrypt keeps almost no state
+except what you see in your buffer, so any action can be undone this
+way.
+@item
+All Mailcrypt operations place PGP's output in the @code{*MailCrypt*}
+buffer.  Check it occasionally for status and warning messages.
+@item
+Add yourself to the Mailcrypt announcements mailing list (@pxref{Mailing
+List}).  That way you can find out about new versions of Mailcrypt
+automatically, and we can enjoy the feeling that people are actually
+using our package.
+@end itemize
+@node Limitations, References, Tips, Top
+@chapter Limitations
+Mailcrypt is a powerful program, but it is not a complete PGP interface.
+Perhaps some future version will be; in the meantime, you will need to
+use the command-line interface for some operations.  Things which the
+current version does not support include:
+@table @emph
+@item Complete Key Management
+Mailcrypt's key management support is limited to adding and extracting
+keys from keyrings.  It does not support key generation, key removal,
+key revocation, ID and trust parameter editing, or key signing.  It also
+ignores PGP's warnings when you use a key which is not fully certified.
+(Of course, you can see these warnings by viewing the @code{*MailCrypt*}
+buffer; see @ref{Tips}.)
+@item Encryption with Conventional Cryptography
+Mailcrypt supports decryption but not encryption with "conventional"
+(i.e., non-public key) cryptography.
+@item Detached Signatures
+Mailcrypt does not support the creation nor the verification of detached
+signatures.
+@item "For your eyes only" Decryption
+Mailcrypt will be unable to decrypt a file which was encrypted with the
+"for your eyes only" (@samp{-m}) option.  This is actually a bug in PGP,
+which provides no portable way to avoid its paging behavior.
+@end table
+@node References, Credits, Limitations, Top
+@chapter References
+This chapter contains information and pointers to information about
+topics related to PGP and Mailcrypt.
+@menu
+* Online Resources::            Recreational reading with a purpose.
+* Key Servers::                 Keepers of the Global Keyring.
+* Mailing List::                Staying informed while pumping the
+authors' egos.
+* Politics::                    Anarcho-foobarism.
+@end menu
+@node Online Resources, Key Servers, References, References
+@section Online Resources
+@table @file
+@item http://world.std.com/~franl/crypto.html
+"Cryptography, PGP, and Your Privacy", by Fran Litterio.  This page is
+simply excellent.  It makes all the other References in this chapter
+redundant, but we will include them anyway for redundancy.
+@item http://web.mit.edu/network/pgp.html
+MIT is the canonical distribution site for PGP; this is the announcement
+page.
+@item ftp://rtfm.mit.edu/pub/usenet/alt.security.pgp/
+This is an archive site for the @file{alt.security.pgp} FAQ lists.
+@item news:alt.security.pgp
+The @file{alt.security.pgp} newsgroup is a good place to go for
+discussion about PGP, as well as any topic which any fool anywhere ever
+thinks is related to PGP.  It is also a good last resort for getting
+answers to questions, but please read the FAQ lists first.
+@item http://pgp.ai.mit.edu/~bal/pks-toplev.html
+Brian LaMacchia (bal@@zurich.ai.mit.edu) has put together a World Wide
+Web interface to the public key servers (@pxref{Key Servers}).
+Mailcrypt uses this interface by default when attempting to fetch keys
+via HTTP (@pxref{HTTP Fetch}); most people get to his interface through
+this page.
+@item ftp://ftp.csua.berkeley.edu/pub/cypherpunks/Home.html
+The Cypherpunks are dedicated to taking proactive measures to ensure
+privacy in the digital age.  They wrote the software for, and operate
+many of, the anonymous remailers currently in existence.
+@item http://www.cs.berkeley.edu/~raph/
+Raph Levien actively maintains a remailer list which Mailcrypt knows how
+to parse.  If you are impressed by how easy it is to configure
+Mailcrypt's remailer functions, Raph is the one to thank.  Raph's page
+also has many useful links.
+@item http://www.obscura.com/~loki/
+Lance Cottrell is the author of Mixmaster.  His home page is the
+canonical source for information on Mixmaster and is a good source for
+PGP pointers in general.
+@end table
+@node Key Servers, Mailing List, Online Resources, References
+@section Key Servers
+@dfn{Key servers} are machines with a publicly accessible interface to
+an enormous global public keyring.  Anyone may add keys to or query this
+keyring.  Each key server holds a complete copy of the global keyring,
+and they arrange to keep one another informed of additions they receive.
+This means you can tell any key server to add your public key to the
+global keyring, and all of the other servers will know about it within a
+day or so.  Then anyone will be able to query any key server to obtain
+your public key.
+To add your key to the keyservers, send an Email message to
+@code{pgp-public-keys@@pgp.ai.mit.edu} with a subject line of @samp{ADD}
+and a body containing your public key block.  With Mailcrypt installed,
+you can just type @kbd{C-c / x} to insert your public key block
+(@pxref{Inserting Keys}) into the body of the message.
+For help with the Email interface to the key servers, send a message
+with a subject line of @samp{HELP}.  For a World Wide Web interface to
+the key servers, see Brian LaMacchia's home page at
+@file{http://www-swiss.ai.mit.edu/~bal/}.
+Some other key servers include:
+@itemize @bullet
+@item
+pgp-public-keys@@jpunix.com
+@item
+pgp-public-keys@@kub.nl
+@item
+pgp-public-keys@@uit.no
+@item
+pgp-public-keys@@pgp.ox.ac.uk
+@end itemize
+For a complete list, consult any good online repository of PGP
+information (@pxref{Online Resources}).
+It is strongly recommended that you submit your key to the key servers,
+since many humans and programs (including Mailcrypt) may look for it
+there.  Besides, it takes mere seconds and the pain passes quickly.
+@node Mailing List, Politics, Key Servers, References
+@section Mailing List
+If you would like to automatically receive information about new
+releases of Mailcrypt, send Email to
+@samp{mc-announce-request@@cag.lcs.mit.edu} asking to be placed on the
+@samp{mc-announce} mailing list.  The mailing list is maintained
+manually, so please be patient.
+The @samp{mc-announce} list is reserved for announcements of new
+Mailcrypt versions, so it has extremely low volume.  We encourage you to
+add yourself so we can get a rough idea of how many people are using
+our package.
+@node Politics,  , Mailing List, References
+@section Politics
+Cryptography in general, PGP in particular, and free software are
+politically somewhat controversial topics.  Heck, in the U.S. Congress,
+freedom of speech is a controversial topic.  Anyway, here are some
+organizations you should definitely watch and preferably send lots of
+money.
+@table @emph
+@item The Electronic Frontier Foundation
+The EFF (@file{http://www.eff.org/}) works to protect civil liberties in
+cyberspace.  They also maintain an impressive collection of on-line
+resources.  If you like Mailcrypt so much that you wish you had paid for
+it, this is the number one place we would want to see your money go.
+The EFF newsgroups, @file{comp.org.eff.news} and
+@file{comp.org.eff.talk}, are required reading for the well-informed.
+@item The League for Programming Freedom
+The LPF (@file{http://www.lpf.org/}) works to fight software patents,
+which threaten to make free software like Mailcrypt impossible.
+@item The Center for Democracy and Technology
+The CDT (@file{http://www.cdt.org/}) has essentially the same goals as
+the EFF, but is more of a lobbying group.
+@end table
+Mailcrypt's remailer support was inspired by the Communications Decency
+Act of 1995 (see @file{http://www.cdt.org/cda.html}) and by the
+International "Church" of Scientology (see
+@file{http://www.mit.edu:8001/people/rnewman/scientology/}).
+@node Credits, Index, References, Top
+@chapter Credits
+Mailcrypt was written by Jin Choi (jin@@atype.com) and Pat LoPresti
+(patl@@lcs.mit.edu).  Please send us your bug reports and comments.
+Also see @ref{Mailing List}.
+This documentation was mostly written by Pat LoPresti, but borrows
+heavily from an earlier version by Hal Abelson (hal@@mit.edu).
+Mailcrypt would not be as robust nor as featureful if it were not for
+our outstanding set of Beta testers:
+@itemize @bullet
+@item
+Samuel Tardieu <sam@@inf.enst.fr>
+@item
+Richard Stanton <stanton@@haas.berkeley.edu>
+@item
+Peter Arius <arius@@immd2.informatik.uni-erlangen.de>
+@item
+Tomaz Borstnar <tomaz@@cmir.arnes.si>
+@item
+Barry Brumitt <belboz@@frc2.frc.ri.cmu.edu>
+@item
+Steffen Zahn <Steffen.Zahn%robinie@@sunserv.sie.siemens.co.at>
+@item
+Mike Campbell <mcampbel@@offenbach.sbi.com>
+@item
+Mark Baushke <mdb@@cisco.com>
+@item
+Mike Long <mike.long@@analog.com>
+@end itemize
+@node Index,  , Credits, Top
+@unnumbered Index
+This index has an entry for every key sequence, function, and variable
+documented in this manual.
+@printindex cp
+@contents
+@bye
+@c End:

Mercurial > hg > xemacs-beta

comparison man/mailcrypt.texi @ 0:376386a54a3c r19-14