NAME¶
kuvert - Automatically sign and/or encrypt emails based on the recipients
SYNOPSIS¶
kuvert [-d] [-o] [-r|-k]
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.
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 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 actions:
- 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.
- 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.)
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 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.
- 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" <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" 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¶
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 above.
- 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.
- 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.
- 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
<http://refspecs.linux-foundation.org/LSB_2.0.0/LSB-Core/LSB-Core.html#BASELIB-SENDMAIL-1>).
- 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 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, RFC2440, RFC2015
AUTHOR¶
Alexander Zangerl <az@snafu.priv.at>
COPYRIGHT AND LICENCE¶
copyright 1999-2008 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.