This 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: OpenVMS VAX V5.5
or later
OpenVMS AXP V6.1 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 (e.g.,
invoke 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 an odd-valued status code if successful
and an even-valued status code if unsuccessful.
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_COM:CONVERT.COM 'INPUT_FILE' 'OUTPUT_FILE'"
executes the command @PMDF_COM:CONVERT.COM 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 command procedure,
PMDF_COM:COMPRESS.COM: in-chan=bsout_*; part-number=1; in-type=*; in-subtype=*;
service-command="@PMDF_COM:COMPRESS.COM COMPRESS 'INPUT_FILE' 'OUTPUT_FILE'"
out-chan=bsin_*; part-number=1; in-type=application;
in-subtype=compressed-bsmtp;
service-command="@PMDF_COM:COMPRESS.COM DECOMPRESS 'INPUT_FILE' 'OUTPUT_FILE'"
The COMPRESS.COM command procedure is shown in Figure
1-1 .
Figure 1-1 COMPRESS.COM: Compress and decompress BSMTP
payloads
$ !
$ ! Compress/decompress a MIME message using GZIP & GUNZIP
$ ! P1 == "COMPRESS" | "DECOMPRESS"
$ ! P2 == File to compress or decompress
$ ! P3 == File containing the compressed or decompressed result
$ !
$ ! Ensure that we have three command line arguments
$ IF P1 .EQS. "" THEN EXIT 229448 ! DCL-W-INSFPRM
$ IF P2 .EQS. "" THEN EXIT 229448
$ IF P3 .EQS. "" THEN EXIT 229448
$ !
$ ! Used for temporary files
$ OUTFILE = F$ELEMENT(0,";",P3)
$ !
$ ! Dispatch to the correct part of this command file
$ IF "DECOMPRESS" .EQS. F$EDIT(P1,"TRIM,UPCASE) THEN GOTO DECOMPRESS
$ IF "COMPRESS" .NES. F$EDIT(P1,"TRIM,UPCASE) THEN EXIT 229472 ! DCL-W-IVKEYW
$ !
$ COMPRESS:
$ GZIP = "$PMDF_EXE:GZIP.EXE"
$ DEFINE/USER SYS$OUTPUT 'OUTFILE'-TMP
$ GZIP -C 'P2'
$ PMDF ENCODE/HEADER/TYPE=APPLICATION/SUBTYPE=COMPRESSED-BSMTP -
'OUTFILE'-TMP 'P3'
$ DELETE/NOLOG 'OUTFILE'-TMP;*
$ EXIT 1
$ !
$ DECOMPRESS:
$ GUNZIP = "$PMDF_EXE:GUNZIP.EXE"
$ PMDF DECODE/HEADER 'P2' 'OUTFILE'-TMP
$ DEFINE/USER SYS$OUTPUT 'P3'
$ GUNZIP -C 'OUTFILE-TMP'
$ DELETE/NOLOG 'OUTFILE'-TMP;*
$ EXIT 1
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 command procedure
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 command procedures: in-chan=bsout_*; part-number=1; in-type=*; in-subtype=*;
service-command="@PMDF_COM:PGP_SIGN.COM 'INPUT_FILE' 'OUTPUT_FILE'"
out-chan=bsin_*; part-number=1; in-type=multipart; in-subtype=signed;
service-command="@PMDF_COM:PGP_VERIFY.COM 'INPUT_FILE' 'OUTPUT_FILE'"
These two command procedures are shown in Figures 1-2 and
1-3
. They assume that the PGP utility is the image D1:[PGP]PGP.EXE.
Note that the PGP_SIGN.COM procedure requires the pass phrase for
the PMDF MTA's private PGP key in order to generate signatures. Edit the
procedure to reflect the correct pass phrase and be sure to protect the file
from other users: $ SET FILE/OWNER=[PMDF] PMDF_COM:PGP_SIGN.COM
$ SET PROTECTION=(S:RWED,O:RWED,G,W) PMDF_COM:PGP_SIGN.COM
Figure 1-2 PGP_SIGN.COM: Digitally sign BSMTP payloads
$ ! P1 == Input file specification; message to sign
$ ! P2 == Output file specification; multipart/signed message
$ ! P3 == File specification for the file of envelope recipient addresses
$ !
$ ! Check that we have at least two command line parameters
$ IF P1 .EQS. "" THEN EXIT 229448 ! DCL-W_INSFPRM
$ IF P2 .EQS. "" THEN EXIT 229448
$ !
$ ! Basic definitions
$ PGP = "$D1:[PGP]PGP.EXE"
$ PGPUSER = "PMDF MTA key"
$ PGPPATH = "PMDF_ROOT:[TABLE.PGP]"
$ PGPPASS = "Percy eats pealed bananas"
$ FILENAM = F$ELEMENT(0,";",P2)
$ !
$ ! Error handling
$ ON ERROR THEN GOTO ERROR
$ ON SEVERE_ERROR THEN GOTO ERROR
$ !
$ ! Generate the digital signature
$ PGP "-sab" "-u" "''PGPUSER'" "-z" "''PGPPASS'" 'P1' "-o" 'FILENAM'-SIGN -
"+batchmode"
$ !
$ ! Get a unique string to use in a MIME boundary marker
$ RUN PMDF_EXE:UNIQUE_ID.EXE
$ BOUNDARY = "''unique_id'"
$ !
$ ! Start the multipart message and the first message part
$ OPEN/WRITE/ERROR=ERROR OUTFILE 'P2'
$ WRT = "WRITE/ERROR=ERROR OUTFILE"
$ WRT "Content-type: multipart/signed; boundary=''BOUNDARY';"
$ WRT " micalg=pgp-md5; protocol=application/pgp-signature"
$ WRT ""
$ WRT "--''BOUNDARY'"
$ CLOSE/ERROR=ERROR OUTFILE
$ !
$ ! Start the second message part
$ OPEN/WRITE/ERROR=ERROR OUTFILE 'FILENAM'-MID
$ WRT "--''BOUNDARY'"
$ WRT "Content-type: application/pgp-signature"
$ WRT ""
$ CLOSE/ERROR=ERROR OUTFILE
$ !
$ ! And the end of the message
$ OPEN/WRITE/ERROR=ERROR OUTFILE 'FILENAM'-BOT
$ WRT "--''BOUNDARY'--"
$ CLOSE/ERROR=ERROR OUTFILE
$ !
$ ! Now glue all of the pieces together
$ CONVERT/APPEND 'P1' 'P2'
$ CONVERT/APPEND 'FILENAM'-MID 'P2'
$ CONVERT/APPEND 'FILENAM'-SIGN 'P2'
$ CONVERT/APPEND 'FILENAM'-BOT 'P2'
$ !
$ ! Delete the temporary files
$ DELETE/NOLOG 'FILENAM'-MID;*,'FILENAM'-SIGN;*,'FILENAM'-BOT;*
$ EXIT 1
$ !
$ ! We fall through to here when we have an error
$ ERROR:
$ SET NOON
$ IF F$TRNLNM("OUTFILE") .NES. "" THEN CLOSE OUTFILE
$ DELETE/NOLOG 'FILENAM'-*.*,'P2'
$ SET ON
$ EXIT 2
Figure 1-3 PGP_VERIFY.COM: Verify the integrity of a digitally signed
BSMTPpayload
$ ! P1 == Input file specification; multipart/signed message
$ ! P2 == Output file specification; message which was signed;
$ ! P3 == File specification for the file of envelope recipient addresses
$ !
$ ! Check that we have at least two command line parameters
$ IF P1 .EQS. "" THEN EXIT 229448 ! DCL-W-INSFPRM
$ IF P2 .EQS. "" THEN EXIT 229448
$ !
$ ! Basic definitions
$ PGP = "$D1:[PGP]PGP.EXE"
$ PGPPATH = "PMDF_ROOT:[TABLE.PGP]"
$ FILENAM = F$ELEMENT(0,";",P2)
$ !
$ ! Error handling
$ ON ERROR THEN GOTO ERROR
$ ON SEVERE_ERROR THEN GOTO ERROR
$ !
$ ! Reformat the input file to look like a PGP signature file
$ OPEN/READ/ERROR=ERROR INFILE 'P1'
$ OPEN/WRITE/ERROR=ERROR OUTFILE 'FILENAM'-SIGN
$ WRT = "WRITE/ERROR=ERROR OUTFILE"
$ STATE = 1
$ LOOP:
$ READ/ERROR=ERROR/END_OF_FILE=END_LOOP INFILE LINE
$ IF STATE .EQ. 1
$ THEN
$ IF F$EXTRACT(0,2,LINE) .EQS. "--"
$ THEN
$ STATE = 2
$ BOUNDARY = LINE
$ WRT "-----BEGIN PGP SIGNED MESSAGE-----"
$ WRT ""
$ ENDIF
$ ELSE
$ IF STATE .EQ. 2
$ THEN
$ IF BOUNDARY .NES. LINE
$ THEN
$ WRT LINE
$ ELSE
$ STATE = 3
$ ENDIF
$ ELSE
$ IF STATE .EQ. 3
$ THEN
$ IF LINE .EQS. ""
$ THEN
$ STATE = 4
$ WRT ""
$ ENDIF
$ ELSE
$ WRT LINE
$ ENDIF
$ ENDIF
$ ENDIF
$ GOTO LOOP
$ !
$ END_LOOP:
$ CLOSE/ERROR=ERROR INFILE
$ CLOSE/ERROR=ERROR OUTFILE
$ !
$ ! Now check the signature
$ DEFINE/USER SYS$OUTPUT 'FILENAM'-CHECK
$ PGP "-o" 'FILENAM'-OUT 'FILENAM'-SIGN "+batchmode"
$ !
$ ! See what the results of the check were; build the X-Content-MIC-check: line
$ SEARCH/OUTPUT='FILENAM'-MIC/EXACT 'FILENAM'-CHECK " signature from user "
$ IF $STATUS .EQ. 1
$ THEN
$ OPEN/READ/ERROR=ERROR INFILE 'FILENAM'-MIC
$ READ/ERROR=ERROR INFILE LINE
$ CLOSE/ERROR=ERROR INFILE
$ MIC_CHECK = "X-Content-MIC-check: "+LINE
$ ELSE
$ MIC_CHECK = "X-Content-MIC-check: Bad signature"
$ ENDIF
$ OPEN/WRITE/ERROR=ERROR OUTFILE 'P2'
$ WRITE/ERROR=ERROR OUTFILE MIC_CHECK
$ CLOSE/ERROR=ERROR OUTFILE
$ !
$ ! Now assemble the result: the MIC check + signed data
$ CONVERT/APPEND 'FILENAM'-OUT 'P2'
$ DELETE/NOLOG 'FILENAM'-*.*
$ EXIT 1
$ !
$ ! We fall through to here when there is an error
$ ERROR:
$ SET NOON
$ IF F$TRNLNM("INFILE") .NES. "" THEN CLOSE INFILE
$ IF F$TRNLNM("OUTFILE") .NES. "" THEN CLOSE OUTFILE
$ DELETE/NOLOG 'FILENAM'-*.*,'P2'
$ SET ON
$ EXIT 2
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
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_ROOT:[TABLE.PGP] is as good as place as any. The easiest way
to set this up is as follows: $ SET DEFAULT PMDF_ROOT:[TABLE]
$ CREATE/DIR/OWNER=[PMDF] [.PGP]
$ PGPPATH == "PMDF_ROOT:[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.
$ DIRECTORY/PROTECTION/SIZE=ALL [.PGP]
Directory PMDF_ROOT:[TABLE.PGP]
PUBRING.BAK;1 1/16 (RWED,RWED,,)
PUBRING.PGP;1 1/16 (RWED,RWED,,)
RANDSEED.BIN;1 1/16 (RWED,RWED,,)
SECRING.PGP;1 2/16 (RWED,RWED,,)
Total of 4 files, 5/64 blocks.
The final directory command verifies that the correct three PGP files
have been created with appropriate rights.
- You may wish change the protections of the file
PUBRING.PGP
so that others can read the public key: $ SET PROTECTION=(W:RE) [.PGP]PUBRING.PGP
- Now you need to sign your public key. This prevents someone else from
modifying the userID 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 keyrings 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
|
