Provided by: kuvert_2.2.2_amd64 
NAME
kuvert - Automatically sign and/or encrypt emails based on the recipients
SYNOPSIS
kuvert [-d] [-o] [-r|-k] [-c configfile]
DESCRIPTION
Kuvert is a tool to protect the integrity and secrecy of your outgoing email independent
of your mail client and with minimal user interaction.
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.
OPTIONS
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.
-c <configfile>
Tells kuvert to use the given config file instead of ~/.kuvert.
OPERATION
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 used.
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 mechanism.
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 choice.
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 options available for secret caching, for example the Linux
in-kernel keystorage (keyctl(1)).
How Kuvert Decides What (Not) To Do
For each recipient, kuvert can be told to apply one of five different action overrides:
none
The email is sent as-is (except for configuration directive removal).
signonly
The email is (clear/detached-) signed.
fallback
The email is encrypted and signed if there is a key available for this recipient or
only signed if not.
fallback-all
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.)
mustencrypt
The mustencrypt action is an "all-or-nothing" action and ensures that any emails
involving such addresses are only sent out if the emmail can be encrypted for every
recipient.
The email is rejected and not sent to anybody at all, if any addresses are present
that have the mustencrypt directive set but where no key is known. Bcc'd recipients
are included in this decision.
This action overrides fallback-all.
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 and no
signing" for some addresses, then this cannot be overridden in a blanket fashion.)
4. Kuvert then analyzes each recipient email address. If an address has the format
Some Text "action=someaction" <user@some.host>", kuvert strips the quoted part and
overrides the addressee's action with someaction.
5. If any "mustencrypt" recipient action is present, but no key is known (or given in an
override, see section "Key Selection"), then the whole mail is rejected and not sent
to anybody.
6. 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".
7. Recipients which are given in a Bcc: header are always treated independently and
separately from all others (except for mustencrypt): 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" <user@some.host>
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" <user@some.host>
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.
CONFIGURATION
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 specifications.
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", "fallback-all" or
"mustencrypt"; 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
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. kuvert uses your
locale's encoding for all messages sent to syslog.
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 above. kuvert uses your locale's
encoding for saving data to the logfile.
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> 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.
preamble <boolean>
Whether kuvert should include an explanatory preamble in the generated MIME mail.
Default: true
interval <number>
This sets the queue checking interval in seconds. Default: 60 seconds.
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.
ssl <string>
Whether SSL or STARTTLS are to be used for outbound SMTP submission. The value must
be either "starttls" to use STARTTLS or "ssl" for raw SSL. SSL encryption is not used
if this option is unset.
ssl-cert <client cert path.pem>
ssl-key <client key path.pem>
ssl-ca <ca cert path.pem>
If an SSL client certificate is to be presented to the SMTP server, set both ssl-cert
and ssl-key. If your system-wide CA certificate setup doesn't include the certificate
your SMTP server uses, set ssl-ca to point to a PEM file containing all the relevant
CA certificates. All these are ignored if the ssl option isn't set.
msuser <username>
The username to use for SMTP authentication at the Mail Submission Server. SMTP Auth
is not attempted if msuser isn't set. Ignored if msserver is not set.
mspass <password>
The password for SMTP authentication. Ignored if msserver or msuser are not set.
mspass-from-query-secret <boolean>
Whether the mspass should be retrieved using the query-secret program instead of
giving the mspass in the config file. Ignored if msserver or msuser are not set. If
this option is set, the query-secret program will be used to ask for the "smtp-
password" when the first mail is processed. The password will be cached if
authentication succeeds or you will be asked again, until authentication succeeds.
msp <program-path and args>
Defines the program kuvert should use to deliver email. Default: "/usr/sbin/sendmail
-om -oi -oem". This 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
<http://refspecs.linux-foundation.org/LSB_2.0.0/LSB-Core/LSB-Core.html#BASELIB-SENDMAIL-1>).
gpg <program-path>
Defines which custom GnuPG executable kuvert should use. If this option is given the
argument must be a full path to an executable. Default: "gpg", i.e. anywhere in the
path.
can-detach <boolean>
Indicates to kuvert that it can background itself on startup, detaching from the
terminal. Default: false.
Detaching works only if your chosen mechanism for passphrase entry doesn't require
interaction via the original terminal. This is the case if you delegate passphrase
handling to gpg-agent and configure it for X11 pinentry, or if your secret-query
program 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 127.0.0.1 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.
DIAGNOSTICS
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.
ENVIRONMENT AND SIGNALS
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.
FILES
~/.kuvert
The configuration file read by kuvert and kuvert_submit.
~/.kuvert_queue
The default queue directory.
/tmp/kuvert.pid.<uid>
holds the pid of a running kuvert daemon.
SEE ALSO
gpg(1), kuvert_submit(1), RFC3156, RFC4880, RFC2015
AUTHOR
Alexander Zangerl <az@snafu.priv.at>
COPYRIGHT AND LICENCE
copyright 1999-2014 Alexander Zangerl <az@snafu.priv.at>
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.