18 April 1997This document describes how to tunnel
messages between two or more cooperating PMDF systems using Batch SMTP (BSMTP).
In addition, use of PMDF's general conversion facilities to provide services
such as payload compression and digital signatures for authentication and
integrity is described.
Software Version: PMDF-MTA V5.1-9
Operating System and Version: Tru64 Unix V3.2
or later
Solaris SPARC V2.5 or later
Solaris Intel V2.5 or later
Batch SMTP (BSMTP) is a batch-mode implementation
of the SMTP protocol which turns SMTP into a remote-submission protocol. For
over a decade, batch SMTP was used quite heavily as a message transfer protocol
on the international BITNET network. Cooperating PMDF sites can use BSMTP as an
effective means of moving mail in bulk between one another; for instance the
exchange of company e-mail between two company offices by means of the Internet.
With BSMTP, messages are bundled together on one PMDF system and then
periodically transmitted through arbitrary MTAs and networks to a remote PMDF
system. Upon receipt at the remote system, the bundle is unpacked and the
individual messages sent on to their recipients. With PMDF's general conversion
facilities, arbitrary transformations can be performed on the bundles such as
document conversion, compression, addition of digital signatures for
authentication and integrity, etc. This document provides examples of
compression using the Free Software Foundation's GZIP and GUNZIP utilities and
authentication using Pretty Good Privacy, Inc.'s PGP® utility.¹
Use of PGP for commercial purposes requires a license
from Pretty Good Privacy, Inc. Please contact Pretty Good Privacy, Inc. for
details and assistance in licensing PGP. PGP is a registered trademark of Philip
Zimmerman.
Each of the PMDF systems which
will be exchanging mail via BSMTP will need one incoming BSMTP channel and an
outgoing BSMTP channel for each of the remote PMDF systems. The channel
definitions bsin_gateway smtp
bsin.host0
bsout_remote1 smtp master user bsmtp daemon host1
BSOUT-REMOTE1
bsout_remote2 smtp master user bsmtp daemon host2
BSOUT-REMOTE2
...
bsout_remoteN smtp master user bsmtp daemon hostN
BSOUT-REMOTEN
where host0 is the name of the local PMDF host and
which will be used by the other remote PMDF systems, and
host1, host2, ...,
hostN are the host names of the remote PMDF systems. The
strings remote1, remote2, ...
remoteN and REMOTE1,
REMOTE2, ..., REMOTEN are arbitrary
and need just be distinct from one another.
With the above definitions, the channel
bsout_remote1 will bundle up its BSMTP
parcels and send them on to the fixed address
bsmtp@host1. Likewise for the remaining
bsout_ channels.
The rewrite rules appear as domain1 $U%$H@BSOUT-REMOTE1$Nbsout_remote1
.domain1 $U%$H$D@BSOUT-REMOTE1$Nbsout_remote1
domain2 $U%$H@BSOUT-REMOTE2$Nbsout_remote2
.domain2 $U%$H$D@BSOUT-REMOTE2$Nbsout_remote2
...
domainN $U%$H@BSOUT-REMOTEN$Nbsout_remoteN
.domainN $U%$H$D@BSOUT-REMOTEN$Nbsout_remoteN
where domain1, domain2, ...
domainN are the domain names of the remote PMDF systems.
Finally, add to the FORWARD mapping table the entry FORWARD
bsmtp@host0 bsmtp@bsin.host0$Y
where, again, host0 is the host name for the local
PMDF system which will be used by the bsout_ channels on the remote
PMDF systems. That way, when they send BSMTP parcels to
bsmtp@host0, it will be forwarded on to the
local bsin_gateway channel.²
For example, assume that domain.com domain will be exchanging BSMTP traffic
with the domain.co.uk domain via the PMDF hosts hub.domain.com and
athena.domain.co.uk. Then hub.domain.com would have the configuration domain.co.uk $U%$H@BSOUT-REMOTE1$Nbsout_remote1
.domain.co.uk $U%$H$D@BSOUT-REMOTE1$Nbsout_remote1
...
bsin_gateway smtp
bsin.hub.domain.com
bsout_remote1 smtp master user bsmtp daemon athena.domain.co.uk
BSOUT-REMOTE1
and the FORWARD mapping table entry FORWARD
bsmtp@hub.domain.com bsmtp@bsin.hub.domain.com$Y
The system athena.domain.co.uk would have the configuration domain.com $U%$H@BSOUT-REMOTE1$Nbsout_remote1
.domain.com $U%$H$D@BSOUT-REMOTE1$Nbsout_remote1
...
bsin_gateway smtp
bsin.athena.domain.co.uk
bsout_remote1 smtp master user bsmtp daemon hub.domain.com
BSOUT-REMOTE1
and the FORWARD mapping table entry FORWARD
bsmtp@athena.domain.co.uk bsmtp@bsin.athena.domain.co.uk$Y
With the above configurations, when a user on hub.domain.com sends mail to
user@domain.co.uk, the message is routed to the bsout_remote1 channel. That
channel will package the message up into a BSMTP parcel and send that parcel on
to bsmtp@athena.domain.co.uk. Owing to the $Nbsout_remote1 tag in the
domain.co.uk rewrite rules, those rewrite rules will be ignored when the
bsout_remote1 channel enqueues the message. Instead, the normal rewrite rules
for domain.co.uk will take effect and route the message containing the parcel
out to the WAN (e.g., the Internet).
Note that the outbound BSMTP channels can construct application/batch-smtp
message parts containing multiple messages. As such, sites may wish to use the
after channel keyword on their bsout_ channels. So
doing may prove advantageous for sites who wish to bundle their mail up into
large parcels and send those parcels only once every few minutes, hours, or
days. Also, the SEPARATE_FILES channel option might be used with the
bsout_ channels to prevent cases where, under heavy load, a
bsout_ channel just runs continuously bundling into a single parcel
messages queuing up to be sent out. This option puts an upper limit on the
number of messages placed in a single parcel and forces the channel to close a
parcel, send it along, and start a new parcel when there are lots of messages to
bundle up.
Any of several mechanisms might be used to accomplish
this forwarding. The most efficient is the use of an alias when
host0 is the official local host name for the PMDF system.
The least efficient is the FORWARD mapping table; which method is best for a
given site depends upon site-specific issues. Use of the FORWARD mapping table
is presented here because that method works in all cases.
PMDF's conversion service facility may be used to process with site-supplied
procedures a message so as to produce a new form of the message. Unlike the
conversion channel which operates on the content of individual MIME message
parts, conversion services operate on entire MIME message parts (MIME headers
and content) as well as entire MIME messages. Also, unlike conversion channel
operations, conversion services are expected to do their own MIME disassembly,
decoding, re-encoding, and reassembly.
Like the conversion channel, conversion services are enabled through the
CHARSET-CONVERSION mapping table. For the purposes of this document, entries for
conversion services appear in the /pmdf/table/conversions file in
the format in-chan=channel-pattern; part-number=1;
in-type=type-pattern; in-subtype=subtype-pattern;
service-command=command
Of key interest is the command string. This is the
command which should be executed to perform a service conversion such as
invoking a document converter. The command must process an input file containing
the message text to be serviced and produce as output a file containing the new
message text. The command must exit with a 0 if successful and a non-zero value
otherwise.
Environment variables are used to pass the names of the input and output
files as well as the name of a file containing the list of the message's
envelope recipient addresses. The names of these environment variables are:
| Variable |
Usage |
| INPUT_FILE |
Name of the input file to process |
| OUTPUT_FILE |
Name of the output file to produce |
| INFO_FILE |
Name of the file containing envelope recipient
addresses |
The values of these three environment
variables may be substituted into the command line by preceding and following
the variable's name with an apostrophe. For example, when
INPUT_FILE and OUTPUT_FILE have the values
a.in and a.out, the following declaration, in-chan=bsout_*; part-number=1; in-type=*; in-subtype=*;
service-command="/pmdf/bin/convert.sh 'INPUT_FILE' 'OUTPUT_FILE'"
executes the command /pmdf/bin/convert.sh a.in a.out
Using PMDF's general purpose, on-the-fly conversion facilities,
BSMTP parcels can be compressed on the sending system and then uncompressed on
the receiving system. This allows for faster transmission of the parcels through
the network.
In the CHARSET-CONVERSION mapping table on each PMDF system, a simple entry
enabling conversions for the BSMTP channels must be made: CHARSET-CONVERSION
in-chan=bsout_*;out-chan=*;convert yes
in-chan=*;out-chan=bsin_*;convert yes
In the /pmdf/table/conversions file on each system, conversion
entries are added which call out to the site-supplied shell script,
compress.sh: in-chan=bsout_*; part-number=1; in-type=*; in-subtype=*;
service-command="/pmdf/bin/compress.sh compress 'INPUT_FILE' 'OUTPUT_FILE'"
out-chan=bsin_*; part-number=1; in-type=application;
in-subtype=compressed-bsmtp;
service-command="/pmdf/bin/compress.sh decompress 'INPUT_FILE' 'OUTPUT_FILE'"
The compress.sh shell script is shown in Figure
1-1 . It assumes that the gzip and gunzip
utilities are installed in /usr/local/bin/.
Figure 1-1 compress.sh: Compress and decompress BSMTP
payloads
#!/sbin/sh
# compress operation in-file out-file [addr-file]
# where
# operation == "compress" | "decompress"
# input-file == path of file to sign or verify
# output-file == output file to produce
# addr-file == file of envelope recipient addresses
if [ $# -lt 3 ]; then exit 1; fi
case $1
in
compress )
/usr/local/bin/gzip < $2 > $3.tmp
/pmdf/bin/pmdf encode -nofilename -encoding=base64 -type=application \
-subtype=compressed-bsmtp $3.tmp $3.tmp2
rm -f $3.tmp $3.tmp2
;;
decompress )
/pmdf/bin/pmdf decode $2 $3.tmp
/usr/local/bin/gunzip < $3.tmp > $3
rm -f $3.tmp
;;
* )
exit 1
;;
esac
exit 0
Using PMDF's general purpose, on-the-fly conversion facilities,
authentication and integrity services may be tied in to the BSMTP channels. This
is done through the CHARSET-CONVERSION mapping table, the
/pmdf/table/conversions file, and a site-supplied shell script to
digitally sign payloads and verify the signature and integrity of the data upon
receipt.
In the CHARSET-CONVERSION mapping table on each PMDF system, a simple entry
enabling conversions for the BSMTP channels must be made: CHARSET-CONVERSION
in-chan=bsout_*;out-chan=*;convert yes
in-chan=*;out-chan=bsin_*;convert yes
In the /pmdf/table/conversions file on each system, there must
be conversion entries to invoke the site-supplied shell scripts: in-chan=bsout_*; part-number=1; in-type=*; in-subtype=*;
service-command="/pmdf/bin/pgp_sign.sh 'INPUT_FILE' 'OUTPUT_FILE'"
out-chan=bsin_*; part-number=1; in-type=multipart; in-subtype=signed;
service-command="/pmdf/bin/pgp_verify.sh 'INPUT_FILE' 'OUTPUT_FILE'"
These two scripts are shown in Figures 1-2 and
1-3 .
They assume that the pgp utility is installed in
/usr/local/bin/ and that awk is installed in
/usr/bin/. Note that the pgp_sign.sh script requires
the pass phrase for the PMDF MTA's private PGP key in order to generate
signatures. Edit the script to reflect the correct pass phrase and be sure to
protect the file from other users: % chown pmdf:bin /pmdf/bin/pgp_sign.sh
% chmod 0700 /pmdf/bin/pgp_sign.sh
Figure 1-2 pgp_sign.sh: Digitally sign BSMTP payloads
#!/sbin/sh
# pgp_sign.sh input-file output-file [addr-file]
# where
# input-file == path of file to sign or verify
# output-file == output file to produce
# addr-file == file of envelope recipient addresses
# Check that we have at least three command line parameters
if [ $# -lt 2 ]; then exit 1; fi
# Change these to match your site
PGPUSER="PMDF MTA key"
PGPPATH=/pmdf/table/pgp
PGPPASS="Percy eats pealed bananas"
# Generate the digital signature
/usr/local/bin/pgp -sab $1 -u $PGPUSER -z $PGPPASS -o $2 +batchmode
# Make some temporary files used to MIME-ify the results
BOUNDARY=`/pmdf/bin/unique_id`
echo 'Content-type: multipart/signed; boundary="'$BOUNDARY'"; '\
'micalg=pgp-md5; protocol=application/pgp-signature
--'$BOUNDARY > $2.top
echo '--'$BOUNDARY'
Content-type: application/pgp-signature
' > $2.mid
echo --$BOUNDARY-- > $2.bot
# Make a multipart/signed message part
cat $2.top $1 $2.mid $2.asc $2.bot > $2
# Now clean up
rm -f $2.top $2.mid $2.asc $2.bot
# And exit
exit 0
Figure 1-3 pgp_verify.sh: Verify the integrity of a digitally signed
BSMTPpayload
#!/sbin/sh
# pgp_verify.sh input-file output-file [addr-file]
# where
# input-file == path of file to sign or verify
# output-file == output file to produce
# addr-file == file of envelope recipient addresses
# Check that we have at least three command line parameters
if [ $# -lt 2 ]; then exit 1; fi
# Change this to match your site
PGPPATH=/pmdf/table/pgp
# Use awk to split the multipart/signed part into
# two files: the signed data and the digital signature
/usr/bin/awk '
BEGIN { state = 0 }
{
if (state == 0) {
if (substr ($0, 0, 2) == "--") {
boundary = $0
state = 1
}
} else if (state == 1) {
if ($0 != boundary) {
print $0 > OUT_DATA
} else {
state = 2
}
} else if (state == 2) {
if (NF == 0) state = 3
} else if (state == 3) {
print $0 > OUT_SIGN
}
}' OUT_DATA=$2.data OUT_SIGN=$2.sign $1
# Verify the digital signature
/usr/local/bin/pgp $2.sign $2.data +batchmode > $2.check
# Build a X-Content-MIC-check: header line
MICINFO=`grep -h ' signature from user ' $2.check`
if [ -n "$MICINFO" ]
then
echo 'X-Content-MIC-check: '$MICINFO > $2.mic
else
echo 'X-Content-MIC-check: Bad signature' > $2.mic
fi
cat $2.mic $2.data > $2
# Clean up
rm -f $2.sign $2.data $2.check $2.mic
# And exit
exit 0
Use of PGP for commercial purposes requires a
license from Pretty Good Privacy, Inc. Please contact Pretty Good Privacy,
Inc. for details and assistance in licensing PGP.
Use of PGP requires installation of PGP as well as generation and exchange of
PGP public keys between the PMDF BSMTP systems which will be using PGP for
authentication. This section documents step-by-step how to generate and exchange
PGP keys. No attempt is here made to document PGP. Please refer to the
documentation supplied with PGP for information on those subjects.
- Acquire copies of PGP and install it on the PMDF systems. The following
URLs might be helpful:
<http://www.pgp.com/>
<ftp://ftp.csn.net/mpj/getpgp.asc>
<http://world.std.com/~franl/pgp/where-to-get-pgp.html>
- After installing PGP, create an MTA key for the PMDF system. Note that the
name for the key will be
PMDF MTA key bsmtp@bsin.host0
where host0 is as in Section
1.2 . The important element here is that the remote BSMTP channel will
send the message to the address
bsmtp@host0. The local PMDF system will
receive that message and, via the FORWARD mapping table, route it to the
incoming BSMTP channel, bsin_gateway for the recipient
bsmtp@bsin.host0. This recipient address is
the user id of the decryption key which will be used. The PGP key rings need
to be located somewhere; placing them in the directory
/pmdf/table/pgp/ is as good as place as any. The easiest way to
set this up is as follows: % su pmdf
% cd /pmdf/table
% mkdir pgp
% setenv PGPPATH /pmdf/table/pgp
% pgp -kg
Pretty Good Privacy(tm) 2.6.2 - Public-key encryption for the masses.
(c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. 11 Oct 94
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Distributed by the Massachusetts Institute of Technology.
Export of this software may be restricted by the U.S. government.
Current time: 1997/04/02 20:44 GMT
Pick your RSA key size:
1) 512 bits- Low commercial grade, fast but less secure
2) 768 bits- High commercial grade, medium speed, good security
3) 1024 bits- "Military" grade, slow, highest security
Choose 1, 2, or 3, or enter desired number of bits: 3
Generating an RSA key with a 1024-bit modulus.
You need a user ID for your public key. The desired form for this
user ID is your name, followed by your E-mail address enclosed in
<angle brackets>, if you have an E-mail address.
For example: John Q. Smith <12345.6789@compuserve.com>
Enter a user ID for your public key: PMDF MTA key <bsmtp@bsin.host0>
You need a pass phrase to protect your RSA secret key.
Your pass phrase can be any sentence or phrase and may have many
words, spaces, punctuation, or any other printable characters.
Enter pass phrase: secret
Enter same pass phrase again: secret
Note that key generation is a lengthy process.
We need to generate 736 random bits. This is done by measuring the
time intervals between your keystrokes. Please enter some random text
on your keyboard until you hear the beep:
0 * -Enough, thank you.
....**** ..............****
Key generation completed.
% ls -l pgp
total 6
-rw------- 1 pmdf 30 197 Apr 2 12:52 pubring.pgp
-rw------- 1 pmdf 30 408 Apr 2 12:52 randseed.bin
-rw------- 1 pmdf 30 530 Apr 2 12:52 secring.pgp
The final ls command verifies that the correct three PGP
files have been created with appropriate rights.
- You may wish change the permissions of the file
pubring.pgp
so that others can read the public key: % chmod 644 pgp/pubring.pgp
% ls -l pgp
total 6
-rw-r--r-- 1 pmdf 30 197 Apr 2 12:52 pubring.pgp
-rw------- 1 pmdf 30 408 Apr 2 12:52 randseed.bin
-rw------- 1 pmdf 30 530 Apr 2 12:52 secring.pgp
- Now you need to sign your public key. This prevents someone else from
modifying the user key ringid of the key.
% pgp -ks bsmtp@bsin.host0
Pretty Good Privacy(tm) 2.6.2 - Public-key encryption for the masses.
(c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. 11 Oct 94
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Distributed by the Massachusetts Institute of Technology.
Export of this software may be restricted by the U.S. government.
Current time: 1997/04/02 20:46 GMT
A secret key is required to make a signature.
You specified no user ID to select your secret key,
so the default user ID and key will be the most recently
added key on your secret keyring.
Looking for key for user 'bsmtp@bsin.host0':
Key for user ID: PMDF MTA key <bsmtp@bsin.host0>
1024-bit key, Key ID BFFA43E9, created 1997/04/02
Key fingerprint = 2F 5C A1 0A 35 25 E1 23 ED AF 23 11 00 37 5A CD
READ CAREFULLY: Based on your own direct first-hand knowledge, are
you absolutely certain that you are prepared to solemnly certify that
the above public key actually belongs to the user specified by the
above user ID (y/N)? y
You need a pass phrase to unlock your RSA secret key.
Key for user ID "PMDF MTA key <bsmtp@bsin.host0>"
Enter pass phrase: secret
Pass phrase is good. Just a moment....
Key signature certificate added.
- Repeat Steps (1)---(4) on the other PMDF systems.
- Next, you need to exchange public keys between the PMDF systems. On a
given system, you may extract the public key as follows:
% pgp -kxa bsmtp@bsin.host0 extract
Pretty Good Privacy(tm) 2.6.2 - Public-key encryption for the masses.
(c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. 11 Oct 94
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Distributed by the Massachusetts Institute of Technology.
Export of this software may be restricted by the U.S. government.
Current time: 1997/04/02 20:47 GMT
Extracting from key ring: '/pmdf/table/.pgp/pubring.pgp',
userid "bsmtp@bsin.host0".
Key for user ID: PMDF MTA key <bsmtp@bsin.host0>
1024-bit key, Key ID BFFA43E9, created 1997/04/02
Transport armor file: extract.asc
Key extracted to file 'extract.asc'.
The file extract.asc may then be transferred by FTP or
e-mail to the other PMDF system. If you're exchanging keys with another server
you control go on to the next step. However, if you're exchanging keys with a
remote site, some care needs to be taken to make sure the public keys are
properly certified.
- The best way to exchange keys is to first exchange the key fingerprints
via a reliable channel (e.g., face-to-face in person, or perhaps over
a trusted phone line). The fingerprint can be obtained with the following
command:
% pgp -kvc bsmtp@bsin.host0
Pretty Good Privacy(tm) 2.6.2 - Public-key encryption for the masses.
(c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. 11 Oct 94
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Distributed by the Massachusetts Institute of Technology.
Export of this software may be restricted by the U.S. government.
Current time: 1997/04/02 23:08 GMT
Key ring: '/pmdf/table/.pgp/pubring.pgp', looking for user ID
"bsmtp@bsin.host0".
Type bits/keyID Date User ID
pub 1024/BFFA43E9 1997/04/02 PMDF MTA key <bsmtp@bsin.host0>
Key fingerprint = 2F 5C A1 0A 35 25 E1 23 ED AF 23 11 00 37 5A CD
1 matching key found.
Then the public key itself can be extracted as described in Step (6) and
sent through e-mail. Upon receipt, the fingerprint should be manually verified
before certifying the key. After adding and certifying the key for the remote
server, you may wish to sign that key as well. If you sign the key, and
extract it as described in Step (6) this can be used to tell other people you
believe that key actually belongs to the MTA it claims to belong to. For more
information, see the PGP documentation.
- Add the key in
extract.asc to the key rings on the other PMDF
systems. If you are unsure about how to answer the questions, see the PGP
users guide. % pgp extract.asc
Pretty Good Privacy(tm) 2.6.2 - Public-key encryption for the masses.
(c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. 11 Oct 94
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Distributed by the Massachusetts Institute of Technology.
Export of this software may be restricted by the U.S. government.
Current time: 1997/04/02 21:09 GMT
File contains key(s). Contents follow...
Key ring: 'extract.$00'
Type bits/keyID Date User ID
pub 1024/BFFA43E9 1997/04/02 PMDF MTA key <bsmtp@bsin.host0>
sig BFFA43E9 PMDF MTA key <bsmtp@bsin.host0>
1 matching key found.
Do you want to add this keyfile to keyring '/pmdf/table/.pgp/pubring.pgp' (y/N)? y
Looking for new keys...
pub 1024/BFFA43E9 1997/04/02 PMDF MTA key <bsmtp@bsin.host0>
Checking signatures...
pub 1024/BFFA43E9 1997/04/02 PMDF MTA key <bsmtp@bsin.host0>
sig! BFFA43E9 1997/04/02 PMDF MTA key <bsmtp@bsin.host0>
Keyfile contains:
1 new key(s)
One or more of the new keys are not fully certified.
Do you want to certify any of these keys yourself (y/N)? y
Key for user ID: PMDF MTA key <bsmtp@bsin.host0>
1024-bit key, Key ID BFFA43E9, created 1997/04/02
Key fingerprint = 2F 5C A1 0A 35 25 E1 23 ED AF 23 11 00 37 5A CD
This key/userID association is not certified.
Questionable certification from:
PMDF MTA key <bsmtp@bsin.host0>
Do you want to certify this key yourself (y/N)? y
Looking for key for user 'PMDF MTA key <bsmtp@bsin.host0>':
Key for user ID: PMDF MTA key <bsmtp@bsin.host0>
1024-bit key, Key ID BFFA43E9, created 1997/04/02
Key fingerprint = 2F 5C A1 0A 35 25 E1 23 ED AF 23 11 00 37 5A CD
READ CAREFULLY: Based on your own direct first-hand knowledge, are
you absolutely certain that you are prepared to solemnly certify that
the above public key actually belongs to the user specified by the
above user ID (y/N)? y
You need a pass phrase to unlock your RSA secret key.
Key for user ID "PMDF MTA key <bsmtp@bsin.host1>"
Enter pass phrase: another-secret
Pass phrase is good. Just a moment....
Key signature certificate added.
Make a determination in your own mind whether this key actually
belongs to the person whom you think it belongs to, based on available
evidence. If you think it does, then based on your estimate of
that person's integrity and competence in key management, answer
the following question:
Would you trust "PMDF MTA key <bsmtp@bsin.host0>"
to act as an introducer and certify other people's public keys to you?
(1=I don't know. 2=No. 3=Usually. 4=Yes, always.) ? 2
- Repeat Steps (6)---(8) in the other direction.
- You may check which keys are on your keyring with the following command:
% pgp -kv
Pretty Good Privacy(tm) 2.6.2 - Public-key encryption for the masses.
(c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. 11 Oct 94
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Distributed by the Massachusetts Institute of Technology.
Export of this software may be restricted by the U.S. government.
Current time: 1997/04/02 23:23 GMT
Key ring: '/pmdf/table/.pgp/pubring.pgp'
Type bits/keyID Date User ID
pub 1024/BFFA43E9 1997/04/02 PMDF MTA key <bsmtp@bsin.host0>
pub 1024/6405957D 1997/03/17 PMDF MTA key <bsmtp@bsin.host0>
2 matching keys found.
Once you have exchanged the keys, you should then be able to send digitally
signed BSMTP parcels.
Previous
| Contents
|
