Man Linux: Main Page and Category List


       kuvert - Automatically sign and/or encrypt emails based on the


       kuvert [-d] [-o] [-r|-k]


       Kuvert is a tool to protect the integrity and secrecy of your outgoing
       email independent of your mail client and with minimal user

       It reads mails from its queue (or accepts SMTP submissions), analyzes
       the recipients and decides to whom it should encrypt and/or sign the
       mail. The resulting mail is coerced into the PGP-MIME framework defined
       in RFC3156 and finally sent to your outbound mail server.  Kuvert uses
       GnuPG for all cryptographic tasks and is designed to interface cleanly
       with external secret caching tools.


       After startup kuvert periodically scans its queue directory and
       processes mails from there; depending on your GnuPG passphrase setup
       kuvert may daemonize itself. In either case, kuvert runs forever until
       actively terminated.

       Kuvert’s behaviour is configured primarily using a configuration file,
       with exception of the following commandline options:

       -d  Enables debugging mode: extra debugging information is written to
           STDERR.  (This is independent of normal logging.)

       -o  Enables one-shot mode: kuvert does not loop forever but processes
           only the current queue contents and then exits. Kuvert does also
           not start an SMTP listener in this mode.

       -r  Tells a running kuvert daemon to reload the configuration file and
           the gpg keyring. This is equivalent to sending a SIGUSR1 to the
           respective process.

       -k  Tells a running kuvert daemon to terminate cleanly. This is
           equivalent to sending a SIGTERM to the respective process.


       At startup kuvert reads its configuration file and your gnugp keyring
       and remembers the association of email addresses to keys.

       Kuvert then works as a wrapper around your mail transfer agent (MTA):
       you author your emails like always but instead of sending them out
       directly you submit them to kuvert.

       Periodically kuvert scans its queue and processes any email therein.
       If your keyring contains a key for a recipient, kuvert will encrypt and
       sign the email to that recipient. If no key is available, kuvert will
       only (clear/detached-)sign the email. Subsequently, the email is sent
       onwards using your MTA program or SMTP.

       Emails to be processed can have any valid MIME structure; kuvert
       unpacks the MIME structure losslessly and repacks the
       (encrypted/signed) mail into a PGP/MIME object as described in RFC3156.
       The mail’s structure is preserved. Signature and encryption cover all
       of the mail content with the exception of the top-level headers: for
       example the "Subject" header will be passed in clear, whereas any body
       or attached MIME object will be signed/encrypted.

       The encrypt-or-sign decision can be overridden on a per-address basis
       using the configuration file or, even more fine-grainedly, by using
       directives in the actual email. Kuvert can also be told not to modify
       an email at all.

   Submitting Emails to Kuvert
       Kuvert primarily relies on mails being dumped into its queue directory.
       Kuvert operates on files with numeric file names only. Anything that
       you store in its queue directory with such a filename will be treated
       as containing a single RFC2822-formatted email.

       However, no mainstream MUA supports such a drop-your-files-somewhere
       scheme, and therefore kuvert comes with a helper program called
       kuvert_submit (see kuvert_submit(1))  which mimics sendmail’s mail
       submission behaviour but feeds to the kuvert queue. If your MUA can be
       instructed to run a program for mail submission, kuvert_submit can be

       Alternatively, you can send your email to kuvert via SMTP. Kuvert comes
       with a built-in receive-only mail server, which feeds to the queue
       directory.  As allowing others to submit emails for your signature
       would be silly and dangerous, kuvert’s mail server only listens on the
       localhost IP address and requires that your MUA uses SMTP
       Authentication to ensure that only your submissions are accepted. If
       your MUA supports SMTP AUTH PLAIN or LOGIN and can be told to use
       localhost and a specific port for outbound email, then you can use this

   Transporting Emails Onwards
       Kuvert can send outbound emails either by running a local MTA program
       or by speaking SMTP to some (fixed) outbound mail server of your

   Recipients, Identities and the SMTP Envelope
       In general kuvert identifies recipients using the To, Cc, Bcc and
       Resent-To headers of the queued email. If the mechanism you used to
       submit the mail to kuvert did explicitely set recipients, then these
       override the headers within the email.

       This is the case if kuvert_submit is called with a list of recipients
       and no -t option and for SMTP submission.

       If kuvert enqueues email via inbound SMTP, the SMTP envelope overrides
       the email headers: recipients that are present in the envelope but not
       the headers are treated as Bcc’d, and recipients listed in the headers
       but not the envelope are ignored. Any Resent-To header is ignored for
       SMTP-submitted email.

       Only if no overriding recipients are given, kuvert checks the mail for
       a Resent-To header. If present, the email is sent out immediately to
       the Resent-To addresses without further processing. (This is the
       standard "bounce" behaviour for MUAs that don’t pass recipients on to
       an MSP/MTA directly.)

       When sending outbound email, kuvert usually uses the From header from
       the queued email as identity. If the email was queued via SMTP, the
       envelope again overrides the mail headers.

       Note that kuvert sets the envelope sender using "-f" if sending email
       via a local MTA program; if you are not sufficiently trusted by your
       MTA to do such, your mail may get an X-Authentication-Warning header
       tacked on that indicates your username and the fact that the envelope
       was set explicitely.

   Passphrase Handling
       Kuvert does not handle your precious keys’ passphrases. You can either
       elect to use gpg-agent as an (on-demand or caching) passphrase store,
       or you can tell kuvert what program it should run to query for a
       passphrase when required. Such a query program will be run in a
       pipeline to GnuPG, and kuvert will not access, store or cache the
       passphrases themselves: there are better programs available for secret
       caching, eg. quintuple-agent or the Linux in-kernel keystorage
       (keyctl(1)). Kuvert interfaces cleanly with these.

   How Kuvert Decides What (Not) To Do
       For each recipient, kuvert can be told to apply one of four different

           The email is sent as-is (except for configuration directive

           The email is (clear/detached-) signed.

           The email is encrypted and signed if there is a key available for
           this recipient or only signed.

           The email is encrypted and signed if keys are available for all
           recipients, or only signed otherwise. Recipients whose action is
           set to "none" and Bcc’d recipients are not affected by this action.

           The fallback-all action is an "all-or-nothing" action as far as
           encryption is concerned and ensures that no mix of encrypted or
           unencrypted versions of this email are sent out: if we can we use
           encryption for everybody, or otherwise everybody gets it signed (or
           even unsigned).  (Bcc’d recipients are the exception.)

   Specifying Actions
       Kuvert uses four sources for action specifications: directives in the
       individual email addresses, action directives in the configuration
       file, an X-Kuvert header in your email, and finally the default action
       given in the configuration file.

       1.  First kuvert looks for action directives in your configuration
           file.  Such directives are given as action plus regular expression
           to be matched against an address, and the first matching directive
           is used.

       2.  If no matching directive is found, the default action given in the
           configuration file is applied.

       3.  Kuvert now checks for the presence of an X-Kuvert header: its
           content must be an action keyword, which is applied to all
           recipients of this email except the ones whose action at this stage
           is "none".  (In other words: if you specify "no encryption/signing"
           for some addresses, then this cannot be overridden in a blanket

       4.  Kuvert then analyzes each recipient email address. If an address
           has the format
            Some Text "action=someaction" <>", kuvert strips the
           quoted part and overrides the addressee’s action with someaction.

       5.  Finally kuvert checks if any recipient has action "fallback-all".
           If so, kuvert

           a)  checks if any recipients (except Bcc’d) have action "signonly"
               or "none". If this is the case, all "fallback" and "fallback-
               all" actions are downgraded to "signonly".

           b)  checks if keys for all recipients (except Bcc’d) are available.
               If not, all "fallback" and "fallback-all" actions are
               downgraded to "signonly".

       6.  Recipients which are given in a Bcc: header are always treated
           independently and separately from all others: any "fallback-all"
           action is downgraded to "fallback" for Bcc’d addresses, and if
           encryption is used, the email is encrypted separately so that no
           record of the Bcc’d recipient is visible in the email as sent out
           to the "normal" recipients. Also, any Bcc: header is removed before
           sending an email onwards.

   Key Selection
       Kuvert depends on the order of keys in your keyring to determine which
       key (of potentially many) with a given address should be used for
       encryption.  By default kuvert uses the last key that it encounters for
       a given address.  For people who have multiple keys for a single
       address this can cause problems, and therefore kuvert has override
       mechanisms for encryption key selection: You can specify a key to
       encrypt to for an address in the configuration file (see below), or you
       can override the key selection for and within a single mail:

       If the recipient address is given in the format

        Some Name "key=keyid" <>

       Kuvert will strip the double-quoted part and use this particular key
       for this recipient and for this single email. The keyid must be given
       as the hex key identifier. This mechanism overrides whatever
       associations your keyring contains and should be used with caution.
       Note that both key and action overrides can be given concurrently as a
       single comma-separated entry like this:

        Some Name "action=fallback,key=0x12345" <>

       The signing key can be overridden in a similar fashion: if the From
       address contains a "key=keyid" stanza, kuvert will use this key for
       signing this single email.


       The kuvert configuration file is plain text, blank lines and lines that
       start with "#" are ignored.

       The configuration has of two categories: options and address/action

   Address and Action
       Address+action specifications are given one per line.  Such lines must
       start with some whitespace, followed by an address regexp, followed by
       some whitespace and the action keyword.  For actions "fallback" and
       "fallback-all" kuvert also allows you to specify a single key
       identifier like this: "fallback,0x42BD645D".  The remainder of the line
       is ignored.

       The address regexp is a full Perl regular expression and will be
       applied to the raw SMTP address (i.e. not to the comment or name in the
       email address), case-insensitively. The regular expression may need to
       be anchored with ^ and $; kuvert does not do that for you.  You must
       give just the core of the regexp (no m// or //), like in this example:

        # don't confuse mailing list robots
        ^.*-request@.*$        none

       The action keyword must be one of "none", "signonly", "fallback" or
       "fallback-all"; see section "How Kuvert Decides What (Not) To Do" for
       semantics. Order of action specifications in the config file is
       significant: the search terminates on first match.

       Options are given one per line, and option lines must start with the
       option name followed by some whitespace. All options are case-
       sensitive.  Depending on the option content, some or all of the
       remainder of the option line will be assigned as option value. Inline
       comments are not supported.

       In the following list of options angle brackets denote required
       arguments like this:

        defaultkey <hexkeyid>

       Options that have boolean arguments recognize "1", "on" and "t" as true
       and "0", "off", "f" as false (plus their upper-case versions).  Other
       options have more restricted argument types; kuvert generally sanity-
       checks options at startup.

   Known Options
       syslog <syslog facility or blank>
           Whether kuvert should use syslog for logging, and if so, what
           facility to use. Default: nothing. This is independent of the
           logfile option below.

       logfile <path or blank>
           Whether kuvert should write log messages to a file, appending to
           it.  Default: not set. This is independent of the syslog option

       mail-on-error <email address or blank>
           If kuvert encounters serious or fatal errors, an email is sent back
           to this address if set. Default: undef. This email is sent in
           addition to the normal logging via syslog or logfile.

       queuedir <path>
           Where kuvert and its helper programs store mails to be processed.
           Default: ~/.kuvert_queue. The directory is created if necessary.
           The directory must be owned by the user running kuvert and have
           mode 0700.

       tempdir <path>
           Where kuvert stores temporary files. Default: a directory called
           kuvert.<username>.<pid> in $TMPDIR or /tmp. The directory is
           created if necessary, and must be owned by the user running kuvert
           and have mode 0700.  This directory is completely emptied after
           processing an email.

       identify <boolean>
           Whether kuvert should add an X-Mailer header to outbound emails.
           Default: false. The X-Mailer header consists of the program name
           and version.

       interval <number>
           This sets the queue checking interval in seconds. Default: 60

       msserver <hostname-or-address>
           Mail Submission Server for outbound email. Default: unset.  If this
           is set, kuvert will use SMTP to send outbound emails.  If not set,
           kuvert uses the mail submission program on the local machine.  See
           msp below.

       msport <portnumber>
           The TCP port on which the Mail Submission Server listens. Default:
           587.  Ignored if msserver is not set.

       msp <program-path and args>
           Defines the program kuvert should use to deliver email.  Default:
           "/usr/sbin/sendmail -om -oi -oem" Ths is ignored if msserver is
           set. The argument must include the full path to the program, and
           the program must accept the common mail transfer agent arguments as
           defined in the Linux Standards Base (see

       can-detach <boolean>
           Indicates to kuvert that it can background itself on startup,
           detaching from the terminal. Default: false. This is possible only
           if you either delegate passphrase handling to gpg-agent, or if your
           secret-query program does not require interaction via the original
           terminal (e.g. if it is an X11 program with its own window).

       maport <portnumber>
           Kuvert can accept email for processing via SMTP. This option sets
           the TCP port kuvert listens on (localhost only). Default: 2587.
           Ignored if ma-user and ma-pass are not both set. If you want to use
           this mechanism, tell your mail program to use localhost or
  as outgoing mail server and enable SMTP Authentication
           (see below).

       ma-user <username>
           This option sets the required SMTP authentication username for
           accepting mails via SMTP. Default: undef.  Kuvert does not listen
           for SMTP submissions unless both ma-user and ma-pass are set.
           Kuvert does not accept emails for processing via SMTP unless you
           prove your identity with SMTP Authentication (or anybody on your
           local machine could use kuvert to send emails signed by you!).
           Kuvert currently supports only AUTH PLAIN and LOGIN (which is not a
           major problem as we listen on the loopback interface only). This
           option sets the username kuvert recognizes as yours.  This can be
           anything and doesn’t have to be a real account name.

       ma-pass <password>
           This option sets the password your mail user agent must use for
           SMTP Authentication if submitting mails via SMTP. Default: unset.
           Kuvert does not listen for SMTP submissions unless both ma-user and
           ma-pass are set. This password does not have to be (actually
           shouldn’t be) your real account’s password. Note that using SMTP
           submission requires that you protect your kuvert configuration file
           with strict permissions (0600 is suggested).

       defaultkey <hexkeyid>
           Specifies a default key to use as signing key. Default: unset,
           which means GnuPG gets to choose (usually the first available
           secret key).  Can be overridden in the From: address, see section
           "Key Selection".

       defaultaction <action>
           Which action is to be taken if no overrides are found for a
           recipient.  Default: none. See section "How Kuvert Decides What
           (Not) To Do" for recognized actions.

       alwaystrust <boolean>
           Whether gpg should be told to trust all keys for encryption or not.
           Default: false.

       use-agent <boolean>
           Whether kuvert should delegate all passphrase handling to the gpg-
           agent and call gpg with appropriate options. Default: false.  If
           not set, kuvert will ask the user (or some nominated passphrase
           store) for passphrases on demand.

       query-secret <program-path and args with %s>
           Tells kuvert which program to use for passphrase retrieval.
           Default: "/bin/sh -c ’stty -echo; read -p \"Passphrase %s: \" X; \
           stty echo; echo $X’" Ignored if use-agent is set. Kuvert does not
           store passphrases internally but rather runs the indicated program
           in a pipeline with gpg when signing.  If you use a passphrase store
           (like the Linux-kernel keyutils or secret-agent or the like), enter
           your retrieval program here.  The program is run with kuvert’s
           environment, the first %s in the argument spec is replaced with the
           hex keyid and the passphrase is expected on stdout.  The exit code
           is ignored. If can-detach is not set, the program has access to
           kuvert’s terminal.  Note that the default query program prohibits
           kuvert from backgrounding itself.

       flush-secret <program-path and args with %s>
           This program is called to invalidate an external passphrase cache
           if kuvert is notified by gpg of the passphrase being invalid.
           Default: undef.  Ignored if use-agent is set. The program is run
           with kuvert’s environment and with the first %s of its argument
           spec being replaced by the hex keyid in question. Its exit code is
           ignored. If can-detach is not set, the program has access to
           kuvert’s terminal.


       Kuvert usually logs informational messages to syslog and/or its own
       logfile, both of which can be disabled and adjusted.

       If kuvert detects a fault that makes successful processing of a
       particular email impossible, kuvert will report that on STDERR (if not
       detached) and also email an error report if the option mail-on-error is
       enabled. Such partially or completely unprocessed mails are left in the
       queue but are renamed (the name is prefixed with "failed."); it is up
       to you to either remove such leftovers or rename them to something all-
       numeric once the problem has been resolved.

       The behaviour is similar if fatal problems are encountered; after
       alerting kuvert will terminate with exit code 1.


       Kuvert itself uses only on environment variable: $TMPDIR provides the
       fallback location for kuvert’s temporary directory.

       Kuvert passes its complete environment to child processes, namely gpg
       and any passphrase-query programs.

       On reception of SIGUSR1, kuvert reloads its configuration file and
       keyring.  Any one of SIGHUP, SIGINT, SIGQUIT and SIGTERM causes kuvert
       to terminate cleanly, invalidating the passphrases if a query program
       is used.  All other signals are ignored.


           The configuration file read by kuvert and kuvert_submit.

           The default queue directory.

           holds the pid of a running kuvert daemon.


       gpg(1), kuvert_submit(1), RFC3156, RFC2440, RFC2015


       Alexander Zangerl <>


       copyright 1999-2008 Alexander Zangerl <>

       This program is free software; you can redistribute it and/or modify it
       under the terms of the GNU General Public License version 2 as
       published by the Free Software Foundation.