Howto integrate (G/P)GP into sendmail -D?!

Robin O'Leary
Sat, 11 Nov 2000 01:45:46 +0000

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Looking back through the archives, I came across this thread from
June 2000 about integrating PGP in to sendmail (or an equivalent mail
transfer agent):, at 00:27 +0200 on Fri, 30 Jun 2000, wrote:

> Actually i wonder how to integrate the
> PGP stuff into a sendmaildaemon, since
> i've several users in an intranet and want
> to automatically crypt just the outgoing
> mails... is there a good FAQ about this?!
> BTW, is this stuff usable for VPN's?!
> (FreeBSD/Linux)
This is something I have been keen on doing for some time. Only recently have I investigated other attempts: pgpsendmail ( did much of what I want a few years ago and pgpmail ( updates the idea. But it seems strange to me that nothing like this has been widely adopted. Then I started looking at the gnupg list and from the reaction this question produced, I can see why. I was surprised and disappointed to read the rather abrupt brush-off the idea received from this list. I agree that it would be better if users had encryption-capable mail agents, but surely having an encryption-aware MTA is an excellent first step to getting encryption widely deployed, and, if properly designed, a great way to encourage end-to-end encryption in the future? Why is it such an unpopular idea? First, just to be clear, let me describe the way I see it working: * an organisation installs an encryption-enabled MTA. Preferably this would be implemented as stand-alone filters that could just be dropped in to an existing MTA. * a trusted person generates a key pair for the organisation. This is marked somehow so it can be recognised as belonging to the organisation's whole email domain. The secret key is installed in the MTA; the public part is signed and advertised as usual. * a trusted person configures the MTA with the email addresses and signs the keys of outside recipients (whether they be organisations or individuals) who wish to receive encrypted email. * the MTA checks the recipients on outgoing email against its address/key list. If any records match, the key or keys identified are used to encrypt the email. If some addresses don't match, a policy setting (perhaps influenced by the sender) determines whether the mail is bounced or sent unencrypted. * the MTA decrypts any incoming email that matches the organisation's secret key. That's it---pretty simple. Look at the good things we can do now: An individual outside the organisation (with the necessary software) can now choose to use the organisation's key to communicate securely with any person inside. Of course, if they know an individual's key, they can use that key in preference and the MTA won't interfere. An individual outside can contact the trusted person inside and arrange for their key to be entered in the MTA's database. Now any email sent from inside to the individual outside is automatically encrypted (provided it passes through the MTA). If someone inside decides to install GnuPG themselves, they can tell their correspondents to use their personal key, rather than the organisation key. Also, they can get a quick start by importing the MTA's keyring (assuming they trust the organisation's trusted person, those keys will already be trustworthy). These all seem to be good features. On the bad side, there is the need to store the organisation's secret key securely in the MTA, but at least that problem can be dealt with in one place by employing suitable hardware. I envisage the auto-encrypt and auto-decrypt functions being implemented separately, probably by two SMTP-filters such as those that postfix supports for content-filtering. That way, if no secure crypto-hardware is available, at least the sensitive secret key can be kept on a different machine with better physical and network security since it needs no connections except the filtering service and that is offered only to the MTA. On Thu, 29 Jun 2000 17:42:24 -0500 (CDT) Frank Tobin <> wrot= e:
> This is not a good idea, as there are several flaws that can occur. =20
> First, you have to automate deciding which keys you want to encrypt to...
This doesn't have to be automated to be useful. As discussed above, just having the MTA encrypt to addresses whose keys it has already been taught would work. It seems to me much more likely that an organisation would have one admin person capable of correctly configuring the MTA's keys than that all the email users in the organisation would be capable of doing it themselves. Email users who *were* capable could still do it themselves anyway. It would be great if the MTA could somehow figure out which keys to use automatically, but I believe it is impossible to do this safely without some other communication channel or trusted third party. Still, in a more ambitious scheme than I currently propose it might be possible to automate a human-readable notification that both ends support encryption, so at least the both ends could be prompted to set up new keys.
> ...and this is likely not a system-wide thing you want to enforce.
I would have thought that many organisations would like to enforce a system-wide policy on encryption and would do so if only they had the means. Being able to ensure that, for example, all emails between the parts of a geographically-distributed organisation are encrypted seems quite desirable.
> Second, you would need to be able to handle things like errors
> from GnuPG and such.
Yes, but this is only hard because of GnuPG's current design. The problem is discussed frequently on this list with no resolution yet. It appears that GnuPG is currently available only as a command-line tool. There is no C function interface, although I think I saw a post saying that an attempt has been made to kludge something like it by a wrapper to the command-line version (if so, where it it and are there examples of how to use it?). Currently any program that wants to use GnuPG's features has to be able to invoke it safely (perhaps quoting parameters it wants to pass, worrying about maximum command line lengths), talk to it down one or more pipes (coping with write blocking and signals going off), while simultaneously reading and parsing GnuPG's chatty responses. That is rather daunting, and you are right to raise it as a problem. However, the solution is not to criticise this application for needing a better interface; the solution is to come up with a better interface. Still, even having moaned about it, I think that the current interface would do for this job. The functions needed are all very basic. There is no requirement to do anything but very simple key or trust management, which could even be done on the MTA by the admin running GnuPG by hand in the first instance, although it would be more elegant to have this done by email eventually. If a GnuPG operation failed on an outgoing message, the output could simply be returned to the sender in the same way that any other transport error would be handled. An error on an incoming external encrypted message would be more embarrassing as it might result in the email being unreadable and hence require the sender to re-transmit. Perhaps we can think of some ways to help the administrator make it more robust---perhaps perform an exchange of test messages before accepting a new key.
> And there are a bunch more issues. It's not a plug-and-play scenario.
Such as? Why not? That's not meant rhetorically---I really have thought about it and can't see any negative side here. What problems are there that I haven't thought of?
> GnuPG is designed for user-level usage, as OpenPGP is generally designed
> as an user-to-user protection.
OpenPGP is quite capable of being used in modes other than user-to-user. GnuPG is indeed intended as a user-level interface, and that is appropriate since that is its most common mode of use. But I contend that having no more general interface is a mistake. Perhaps GnuPG is not the right tool for this purpose and I should be addressing some other forum with this discussion; if so, please point me in the right direction. Following further along the thread, I find the same sentiments expressed again: On Thu, 29 Jun 2000 18:18:00 -0700 (PDT), "L. Sassaman" <>= wrote:
> GnuPG is definately designed for user-level usage, but OpenPGP can be
> deployed on a wider scale.
Is there an OpenPGP library? If so, where can I find it? Wouldn't it be better to have GnuPG use that library rather than its own? Having yet another implementation of OpenPGP seems like an invitation for even more inter-operability problems than we have now! On Fri, 30 Jun 2000 01:12:06 +0200 (CEST), Stefan Suurmeijer <stefan@symbol=> wrote:
> Why would you want to integrate it with sendmail? Do you want to use the
> same private key for all users?
Yes, for some organisations this would be ideal.
> Besides, crypting the outgoing mails to which keys? You'd have to have
> the public keys (if they have keys that is) of all recipients.
Yes, just as an individual driving GnuPG does now. But instead of getting each user to do it, it can be done once per organisation.
> Why not integrate pgp with pine for instance and
> have the users choose to encrypt?=20
It's not an exclusive choice; having OpenPGP support in every MUA is the ultimate target. But at the moment, not everyone uses an encryption-capable MUA and getting them to change is difficult---I've tried! Having a way to do encryption centrally in an organisation gets things moving in the right direction and builds a base for inter-operation with more users. Surely it can only be an improvement. Anyway, the crypto-related things needed to get this started are: * ideas on what technology to use underneath * a way to mark an organisation's key for use with a whole email domain * a C library for crypto functions There are some pure implementation details like: * definition of the MTA interface (SMTP in and out?) * how to store the email/key info (private database or GnuPG keyring?) For more ambitious plans, it would also be nice to have: * a way to give a user control over the encryption of a particular message (pgpsendmail uses X-Secure: headers) * an email header to advertise encryption capabilities * a test mode to verify the operation of new keys * a semi-automatic mechanism for exchanging keys * more than one secret key in the MTA so individuals or groups could have their own keys I hope the replies this time around won't be quite so negative:-) Robin. --=20 R.M.O'Leary <> +44 7010 7070 44, PO Box 20, Swansea SA2 8Y= B, UK --5UGlQXeG3ziZS81+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see iQCVAwUBOgykx+zqYp5jhQYZAQG4ZwP9EfUDVNyrWlIP1kxFEp5BxkCi6wyd5Zzs GjqEhiBxGZu0PjzNlfsH+UjZ0dQ+ikMWlGLfrn2PDMwAb5OEThtiCsHNly9cJ6Gv PaLKeSSFuja2MXXaviH//IHweMndvcHScTjgxZ66chWSpafYMp7nplMiFDILQ2D+ zn3cbU6SmSQ= =b/c8 -----END PGP SIGNATURE----- --5UGlQXeG3ziZS81+-- -- Archive is at - Unsubscribe by sending mail with a subject of "unsubscribe" to