 |
Description  |
|
|
RELATED PATENTS
The present invention is related to U.S. Pat. No. 5,029,206, entitled
"Uniform Interface For Cryptographic Services," by Joseph T. Marino, Jr.
and Paul A. Lambert, and to U.S. Pat. No. 4,987,595, entitled "Secure
Cryptographic Processor Arrangement," by Joseph T. Marino, Jr. and Ronald
S. Core, both of which are assigned to the same assignee as the present
application and both of which are hereby incorporated herein by reference.
TECHNICAL FIELD OF THE INVENTION
The present invention relates generally to computer systems and to
communication systems, and, more specifically, to linking computer
security provisions to communication security provisions in the context of
a computer network.
BACKGROUND OF THE INVENTION
A variety of solutions have evolved to provide and maintain the security of
private information. For example, communication security (COMSEC) has
evolved to protect information being communicated over unsecured
communication channels. Generally speaking, COMSEC provides encryption and
decryption standards along with the management of cryptographic
keys/security certificates used in encryption and decryption processes and
communication of private signals over unsecured communication channels.
An alternative field of computer security (COMPUSEC) has evolved to protect
computer-processed information. COMPUSEC provides trusted applications
that maintain separation of data having different security attributes
within a computer system. Trusted/secure applications performed by
computers tightly manage the users who may access the applications,
provide audit trails and limit the types of activities performed to those
for which security can be maintained. An underlying assumption of COMPUSEC
is that protected computer processing takes place within a secure area and
that other procedures are enacted to limit access to the computer and its
data.
Modern computing trends are leading to increased computer networking so
that data may be shared between computers. An increasing number of highly
valuable applications are being developed specifically for networked use.
However, prior art networking technology violates the basic premises upon
which COMPUSEC is founded.
COMSEC provisions might be employed to allow networking of secure computers
over unsecured data channels. Simple porting of COMPUSEC data to a COMSEC
system would not work. A weak security interface exists at the point where
secure information passes between a COMPUSEC protected system (e.g., a
computer) and a COMSEC protected system (e.g., a communication channel).
At this point, opportunities exist for security violations (e.g.,
releasing confidential or classified information to an unauthorized
entity).
SUMMARY OF THE INVENTION
Accordingly, it is an advantage of the present invention that an improved
method of operating a secure node in a computer network is provided.
Another advantage of the present invention is that a secure interface is
provided between a COMPUSEC protected system and a COMSEC protected
system.
Another advantage is that the present invention provides a set of common
communication-oriented services that may achieve a trusted status in a
COMPUSEC protected system.
Another advantage is that the present invention provides a set of common
communication-oriented services that simplify the development of network
applications for secure computers and that simplify the investigations
needed to verify the secure nature of such applications.
The above and other advantages of the present invention are carried out in
one form by a method of operating a secure node in a computer network. The
method calls for performing a trusted process on the secure node. The
trusted process associates security attributes with data provided by the
process. A security kernel for managing communications with other nodes on
the network is established. The security kernel associates communication
security attributes with communication channels. The method additionally
makes a determination concerning whether the trusted process data security
attributes are compatible with the communication security attributes.
BRIEF DESCRIPTION OF THE DRAWINGS
A more complete understanding of the present invention may be derived by
referring to the detailed description and claims when considered in
connection with the Figures, wherein like reference numbers refer to
similar items throughout the Figures and:
FIG. 1 is a nodal diagram of a computer network with which methods for
operating secure computer nodes may be practiced;
FIG. 2 is a block diagram of a secure computer node upon which methods
configured in accordance with the present invention may be practiced;
FIG. 3 is a flow chart of an off-line process performed by a trusted
interface;
FIG. 4 is a diagram of an exemplary data format for an identity-based
access control table utilized by the trusted interface;
FIG. 5 is a flow chart of a first portion of a request for services
procedure performed by the trusted interface;
FIG. 6 is a block diagram of an exemplary data format for a channel
identification table utilized by the trusted interface;
FIG. 7 is a block diagram of an exemplary data format for a local
application access control table maintained by a trusted operating system;
FIG. 8 is a flow chart of a second portion of the request for services
procedure performed by the trusted interface;
FIG. 9 is an exemplary data format diagram of a data packet or block
provided by the trusted operating system and applications running
thereunder;
FIG. 10 shows an exemplary data format diagram of a channel data packet or
block;
FIG. 11 is a flow chart of a third portion of the request for services
procedure performed by the trusted interface; and
FIG. 12 is a flow chart of a fourth portion of the request for services
procedure performed by the trusted interface.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
As employed herein, the terms "server", "file server", "mail server", "file
or mail server" and "file/mail server" are interchangeable and are taken to
mean a server for receiving, storing and/or transmitting files such as
electronic mail, generally as an intermediary between two or more other
entities. FIG. 1 is a nodal diagram of an exemplary computer network 20.
Network 20 includes many computer nodes 22, each of which represents any
type of computerized device, e.g., a workstation, server, router, bridge,
gateway etc., that may transmit or receive data from network 20. The
particular topology illustrated in FIG. 1 is presented for purposes of
illustration only. A portion of nodes 22 are confined in secure areas 24
and are referred to as secure nodes 26. Nodes 22 not confined in secure
areas 24 are referred to as unsecured nodes 28. In some applications,
secure area 24 may be a building or room, while in others, secure area 24
may be a housing or other encasement for computer components.
Secure communication links 30 of network 20 are entirely confined within
secure areas 24 and couple only to secure nodes 26. Unsecured
communication links 32 couple to at least one unsecured node 28 or secured
node 26. Network 20 need not be a secure network, as indicated by the
presence of unsecured nodes 28 and unsecured links 32. Nevertheless, in
accordance with the present invention, isolated unsecured nodes 28 may
operate on network 20 without violating or compromising the security
services and assurances provided within secure areas 24.
FIG. 2 is a block diagram of a secure workstation node 26 upon which
methods configured in accordance with the present invention may be
practiced. Node 26 is characterized as a workstation for convenience in
explaining the present invention, but node 26 is not limited to being only
a workstation. As a secure workstation, node 26 includes secure processor
subsystem 34, security kernel 36 and network processor 38 as described,
for example, in "An INFOSEC Platform for Trusted Products", 15.sup.TH
National Computer Security Conference Proceedings.
Security kernel 36 and network processor 38 represent conventional systems
of hardware and software which provide communication security (COMSEC)
services and assurances related to communicating data over unsecured
network 20. Generally, security kernel 36 provides for key management,
public key exchange sequences, encryption, decryption and related services
used in encrypting private data for transmission over an unsecured channel
and for decrypting data received from the unsecured channel. Security
kernel 36 manages communications by exchanging security certificates
directly with like security kernels 36 in other secure nodes 26 on network
20 or indirectly via unsecured nodes 28 acting as a server for mail or
other file communication applications. Security certificates include a
public encryption key along with other data identifying COMSEC services
being offered. By evaluating security certificates, two security kernels
36 identify an appropriate communication security attribute to associate
with the communication channel. The COMSEC attribute characterizes a level
of security associated with the channel, e.g., confidential, secret, top
secret etc. The above-listed patents provide additional details regarding
the operation of security kernel 36 and network processor 38.
Secure processor subsystem 34 employs conventional computer security
(COMPUSEC) services and assurances to provide for the security of private
data being processed and stored thereon. In many respects, subsystem 34
may resemble a conventional general purpose computer. However, subsystem
34 is usually maintained within the confines of secure area 24 (FIG. 1).
Trusted operating system (TOS) 40 manages the operation of applications 42
performed by subsystem 34. As with general purpose computers, a wide range
and variety of applications may be supported by subsystem 34. However, for
purposes of the present invention, applications 42, such as electronic mail
and others, which import or export data from outside subsystem 34 are the
most relevant.
TOS 40 is a trusted process (i.e., software package) providing COMPUSEC
features. Assurances must be made that the software comprising TOS 40 is
delivered and installed in a trusted manner such that no modifications are
made to the software prior to installation. However, for purposes of the
present invention, a trusted process is one that interfaces with COMSEC
services, whether or not certified. Among the COMPUSEC-related features,
TOS 40 manages log-on provisions, associates data or computer security
attributes with blocks of data processed and stored thereon, manages
application access control and provides for auditing security violations.
Many different trusted operating systems are commercially available.
In addition, trusted driver or interface 44 operates on secure processor
subsystem 34. Interface 44 passes data between security kernel 36 and
operating system 40 and links the COMPUSEC provisions of subsystem 40 with
the COMSEC provisions of security kernel 36. Operation of interface 44 and
network 20 are discussed below (see FIGS. 3-12).
Generally, interface 44 provides a common set of services useful to TOS 40
and to applications 42. These common services form a standard interface
for communicating data from one secure node 26 to another over unsecured
network 20. The standard interface operates under the control of TOS 40
and may itself be certified as being trusted. Applications 42 which import
or export data may rely upon the standard interface to ease their
development. Investigating and evaluating security ramifications of
applications 42 is eased because the opportunity for security violations
diminishes.
FIG. 3 is a flow chart of off-line process 46 performed by trusted
interface 44 (FIG. 2). Off-line process 46 is performed when a security
administrator for secure node 26 (the person responsible for security
provisions with respect to node 26) loads identity based access control
(IBAC) table 48, an exemplary block diagram of which is shown in FIG. 4,
into node 26 for use by interface 44. Process 46 performs task 50 to
obtain IBAC table 48 from a configuration storage device (e.g., disk) and
store table 48 for subsequent on-line access by interface 44.
IBAC table 48 (FIG. 4) includes data associations used by interface 44 in
making access control verifications with respect to requests to pass data
into and out from secure subsystem 34 (FIG. 2). Access control
verifications relate to the manner in which a particular security system
is configured and are implemented to limit access to information in a
manner determined by the security administrator.
IBAC table 48 includes a list of logical network addresses. When
application 42 (FIG. 2) requests communication with another node, the
request references the network address. For each network address, a list
of host addresses may be provided. The list of host addresses determines a
series of hosts comprising a communication path that must be followed in
reaching the specified node. This list may specify routing through any
number of intermediate nodes and processes. When a network address is
omitted from table 48, then application 42 cannot access that network
address.
A link type data element is also associated with network addresses in IBAC
table 48. The link type data element specifies whether the associated
network address may be reached through a secure communication link 30
(FIG. 1) or an unsecured link 32. When secure link 30 is available, the
services of security kernel 36 (FIG. 2) are not required. Communication
may take place through a local application (e.g., application 42') and the
link type data element may specify the identity of application 42'. When
only an unsecured link 32 is available, the services of security kernel 36
are required.
IBAC table 48 also includes one or more stored (e.g., mail) data elements
associated with network addresses. The data elements may be interpreted
differently, depending upon the nature of the entity identified by the
network address (e.g., mail, encrypted files etc.). For example, when a
network address specifies a potential destination entity for mail data,
the mail data elements may specify the identity of a mail server and a
mail box address to use in delivering secure electronic mail. The term
"mail data" refers to data communicated to another node. Electronic mail
facilities are not required and no limitations are applied upon the nature
of the communicated data.
IBAC table 48 may additionally include a separate page for each of several
different source applications 42 (FIG. 2) that may wish to import or
export data. Each page may include a set of network addresses and
associated data valid only for the page's source application 42.
FIG. 5 is a flow chart of a portion of request for services procedure 52
performed by trusted interface 44 (FIG. 2) of secure node 26. Procedure 52
may be invoked when source node 26 wishes to send private data through
network 20 to a destination node 26, when destination node 26 receives
private data or when mail server node 26 receives private data for
temporary storage therein or forwards such data. Procedure 52 includes
several processes selected and performed in response to the requested
service.
Procedure 52 performs initialize channel process 54 as the first part of a
request to exchange private data with a destination. In order to transmit
private data, application 42 (FIG. 2) first initializes and then sends
data through a channel. A request for initializing a channel informs
interface 44 of the network address for which a channel initialization
process 54 is being requested.
Process 54 performs query task 56 to determine whether the destination
specified by the request is authorized to receive private data. Task 56
may evaluate IBAC table 48 (FIG. 4) in making its determination. When the
destination's network address is specified for an appropriate source, the
source entity is authorized to transmit private data to the destination.
However, when the destination's network address is not specified in IBAC
table 48, no authorization is given and task 58 is performed to generate
an audit record and provide the audit record to TOS 40 (FIG. 2), which
records the audit record.
Verification for source entity authorization and auditing of security
violations represent links provided by interface 44 between COMSEC and
COMPUSEC, without which potential exists for private data to be
communicated to entities who have no need to know or for violations to go
unnoticed. When the destination is not authorized, program control exits
process 54 from task 58 and no channel is established or otherwise
initialized.
When task 56 determines that the requested destination entity is
authorized, query task 60 determines whether secure link 30 (FIG. 1) is
available for exchanging data with the destination entity. Task 60 may,
for example, consult IBAC table 48 (FIG. 4) in making its determination.
When no secure link 30 is available, unsecured link 32 (FIG. 1) must be
used and the services of security kernel 36 (FIG. 2) are needed. Thus,
when secure link 30 is not available, task 62 passes the path name of the
destination entity, which may be obtained from the host address list in
IBAC table 48, to security kernel 36 and requests a COMSEC secure channel
initialization through security kernel 36.
Security kernel 36 passes the destination entity name to network processor
38 (FIG. 2) to look up network address information and to establish an
association with the destination's security kernel 36. Source and
destination security kernels 36 use this association to exchange security
certificates. During certificate exchange, source and destination security
kernels 36 send each other security certificates containing logical names
for the devices and COMSEC attributes. Security kernels 36 check that the
names and COMSEC attributes contained in the key material received are the
same as those requested. So long as security provisions are in order,
security kernels 36 then determine the intersection of the devices' COMSEC
attributes and this becomes the COMSEC attribute for the channel currently
being initialized. Additional checks may be performed by security kernels
36. When all these checks pass, traffic (encryption/decryption) keys are
created and stored within the security kernels' memories.
A secure channel has now been initialized through unsecured links 32 (FIG.
1) in network 20. After task 62, interface 44 performs query task 64 to
determine whether the initialization was successful. When initialization
is unsuccessful, task 58 is performed to generate an audit record and
provide the audit record to TOS 40 (FIG. 2). On the other hand, when
secure channel initialization is successful, security kernel 36 passes a
key index, channel ID (representing a logical name assigned to the
initialized channel) and COMSEC attributes for the channel back to
interface 44. The key index represents a code that security kernel 36 may
use later to obtain the traffic encryption key for sending data through
the initialized channel. A similar key index is stored on the network
processor of the destination secure node 26 which is used to obtain the
decryption key for receiving data. The actual traffic keys remain in the
respective security kernels 36.
Task 66 in interface 44 saves the key index and COMSEC attribute in
association with the channel ID in channel ID table 68 (FIG. 6). After
task 66, task 70 sends the channel ID to the application 42 (FIG. 2) that
requested the channel initialization. When application 42 later requests
the sending of data through the initialized channel, it will refer to the
channel by using the channel ID. After task 70, program control exits
process 54.
Referring to task 60, when secure link 30 (FIG. 1) is available for
communicating, services of security kernel 36 are not needed. Accordingly,
process 54 simulates the operation of security kernel 36 to promote
standardization of secure channel usage within network 20, i.e., task 72
creates a channel ID, gets a COMPUSEC attribute to associate with the
secure channel and stores this information in channel ID table 68 (FIG.
6).
The COMPUSEC attribute may be obtained, for example, from a conventional
local application access control table 74, an exemplary block diagram of
which is shown in FIG. 7. TOS 40 (FIG. 2) maintains table 74 in a
conventional manner. Table 74 associates COMPUSEC data security attributes
(e.g., highest and lowest security levels, compartments etc.) with each
application authorized to run at node 26 (FIG. 1). Typically, another
application, such as application 42' (FIG. 2) operates secure link 30
(FIG. 1). Thus, task 72 (FIG. 5) may request TOS 40 to return the COMPUSEC
attribute for the application 42' operating secure link 30. This attribute
may be assigned to the channel being initialized.
Referring to FIG. 5, after task 72, process 54 performs task 70 to send the
channel ID to the requesting application 42 and exits.
FIG. 8 is a flow chart of additional portions of request for services
procedure 52, a first portion of which is shown in FIG. 5. FIG. 8 shows
flow charts for verify integrity process 76, mate COMPUSEC and COMSEC
process 78 and send data process 80. Processes 76, 78 and 80 represent
additional services that may be requested by application 42 or by TOS 40
(FIG. 2).
Verify integrity process 76 is performed to verify the integrity of
software running on secure processor subsystem 34 (FIG. 2). During an
initial load of application 42 onto subsystem 34, a checksum may be
generated and compared against a given value to insure that the integrity
of application 42 remains intact. In addition, this checksum may be
performed at any other time (e.g., whenever application 42 is loaded for
execution).
Process 76 performs task 82 to generate and encrypt or decrypt a checksum,
which may be generated by application 42, TOS 40, interface 44 and/or
security kernel 36 (FIG. 2). Encryption or decryption is desirably
performed in security kernel 36. Encryption may be performed to encrypt a
checksum for storage or for comparison to another encrypted checksum.
Decryption may be performed to decrypt a previously encrypted checksum for
comparison to another checksum.
Query task 84 then determines whether current and previous checksums match.
When checksums match, program control exits process 76 and an "all clear"
message (not shown) may be returned to the requesting entity. When
checksums do not match, task 86 generates an audit record and provides the
record to TOS 40 (FIG. 2).
Mate COMPUSEC and COMSEC process 78 may be performed for either of two
reasons. COMPUSEC attributes may be set to a level compatible with COMSEC
attributes currently established for secure node 26 or a check may be
performed to verify that COMPUSEC and COMSEC attributes are compatible.
Process 78 performs task 88 to get application and communication channel
security attributes. Local application access control table 74 (FIG. 7)
may be consulted to obtain COMPUSEC attributes for a specified application
42. Security kernel 36 may be queried to determine a current COMSEC
attribute.
Query task 90 then compares attributes. This comparison need not look for
equal attributes and may look for an intersection or dominance of
attributes, depending on the security policy being enforced. For example,
when application 42 is authorized to handle "confidential" data and
security kernel 36 is configured to communicate more private "secret"
data, comparable attributes may not be indicated. However, when
application 42 is authorized to handle "secret" data and security kernel
36 is configured to communicate "confidential" data, comparable attributes
may be indicated.
When comparable attributes are indicated, program control may exit process
78 and an "all clear" message (not shown) may be returned to the
requesting entity. When comparable attributes are not indicated, task 92
may generate an audit record and provide the audit record to TOS 40. This
action may be taken when process 78 is performed to verify compatible
COMPUSEC and COMSEC security attributes. Alternatively, task 92 may cause
an application's COMPUSEC attribute in local application access control
table 74 (FIG. 7) to match the COMSEC attribute when process 78 is
performed to set the application's COMPUSEC attribute to an appropriate
level. After task 92 program control exits process 78.
Send data process 80 is requested to send data over a previously
initialized secure channel and represents the second half of a request to
transmit private data. The secure channel may be formed over either secure
link 30 (FIG. 1) or unsecured link 32. Process 80 performs task 94 to get
the data to be sent and the ID of the channel over which the data will be
sent. This information may be passed to interface 44 from application 42
and/or TOS 40 when process 80 is requested.
Task 96 continuously verifies that channel and data security attributes are
consistent. By continuously verifying, task 80 desirably makes its
verification for each block 98, packet or other unit of data passed to it
from TOS 40. FIG. 9 shows an exemplary data format diagram for block 98 of
data passed through TOS 40. Block 98 includes payload data 100 and header
102. Header 102 conveys a COMPUSEC attribute which identifies the data
security level associated with block 98. Other data may also be included
in header 102.
Referring to FIG. 8, the channel security level may be determined by
consulting channel ID table 68 (FIG. 6). A COMSEC channel security
attribute is associated with the channel name given to process 80 from
requesting application 42. Thus, for each block 98 (FIG. 9) of data being
sent away from secure node 26, task 96 verifies compatibility of COMPUSEC
and COMSEC security. When the security linkage cannot be verified, query
task 104 routes program control to task 106, which audits the security
linkage violation by generating an audit record and providing this to TOS
40. Program control then exits process 80.
The following example illustrates the case where data are sent over
unsecured link 32. In the case where data are to be sent over secured link
30, data are simply routed to destination application 42 via the specified
channel ID. When task 104 determines that the security linkage is
verified, task 108 packages data block 98 (FIG. 9) in channel data packet
110, an exemplary data format diagram of which is shown in FIG. 10.
Channel data packet 110 is packaged using a predetermined COMSEC security
protocol (e.g., SP3 or NLSP). The COMSEC attribute portion of the security
protocol may be written to packet 110 (FIG. 10) at interface 44. This
COMSEC attribute may be obtained by consulting channel identification
table 68 (FIG. 6). After task 108, task 112 sends data packet 110 to
security kernel 36 along with the key ID. Security kernel 36 encrypts the
data and may add additional components to the security protocol. Security
kernel 36 passes packet 110 to network processor 38, where it is
eventually transmitted through the identified channel. Program control
then exits process 80.
FIG. 11 is a flow chart of additional portions of request for services
procedure 52, receive data process 114 and post certificate process 116.
In the case where private data are received over unsecured link 32, receive
data process 114 is requested by security kernel 36 when secure node 26 is
a destination for a secure transmission and when private data are
received. When interface 44 is invoked, the private data have been
decrypted through security kernel 36. These data indicate the destination
entity (e.g., a specified application 42) for the data and the COMSEC and
source COMPUSEC attributes for the data. In the case where private data
are received over secured link 30, receive data process 114 is requested
by source application 42 running on the same secure node 26.
Process 114 performs task 118 to get the destination application 42 for the
data and the COMPUSEC attribute associated with the destination. The
destination's COMPUSEC attribute may be obtained from local application
access control table 74 (FIG. 7). Query task 120 then determines whether
security linkages are compatible, i.e., task 120 resolves whether the
COMSEC attribute is compatible with the destination COMPUSEC attribute, as
discussed above. When security linkages are not compatible, task 122 is
performed to audit the security linkage violation, program control exits
process 114, and received data are not presented to the destination
application 42 and may be scrubbed from subsystem 34 (FIG. 2). When task
120 determines that security linkages are compatible, task 124 passes the
data to the intended destination application 42 and exits process 114.
Post certificate process 116 is configured to support secure data storage
functions (e.g., electronic mail) on unsecured network 20. Process 116 is
requested by application 42, e.g., an electronic mail installer program,
during a setup or installation phase and may be requested when security
certificates are changed. Process 116 posts the public security
certificate for the node's security kernel 36 with common unsecure node 28
(e.g., a mail server). This security certificate is used so that other
participating nodes 26 may later receive secure files or electronic mail.
Process 116 performs task 126 to identify applications authorized to
participate in a shared secure file or mail system and may evaluate local
application access control table 74 (FIG. 7) and/or IBAC table 48 (FIG. 4)
in making this determination. Task 128 may, for source and destination
entities authorized as indicated in tables 48 and 74, then identify a file
or mail server to use. The file or mail server may be identified by
consulting the mail data elements associated with a potential destination
authorized to receive secure data or electronic mail.
In the context of secure electronic mail communications or file storage,
the ultimate destination of the data need not be the server itself.
Rather, the destination is that secure node 26 for which the data are
ultimately intended. Unsecure server node 28 may be used to temporarily
store the data until they can be delivered to their ultimate destination.
Likewise, the ultimate destination entity need not be a different node
from the source node. Thus, in some situations, unsecure server node 28
may be used as a remote storage facility for another secure node 26.
Task 130 then causes the COMSEC security certificate held in security
kernel 36 to be posted at the file/mail server. Task 130 operates in a
manner similar to that discussed above for initialize channel process 54
(FIG. 5), except that no real time exchange of certificates is done.
Secure node 26 posting its security certificate sends its security
certificate to the server as occurs when a secure channel is being
initialized. The server saves this security certificate in association
with a file location (e.g., mail box address), which it passes back to the
source of the posted security certificate. When the file location has been
returned, the channel need not remain initialized. Task 132 then updates
IBAC table 48 to reflect the posted status for the node's security
certificate and program control exits process 116.
FIG. 12 is a flow chart of additional portions of request for services
procedure 52, showing flow charts for transmit via storage process 134 and
retrieve from storage process 136. Processes 134 and 136 represent
additional services that may be requested by electronic mail application
42 (FIG. 2) through TOS 40. For purpose of discussion and to provide a
clear example, application 42 is assumed to be an electronic mail
application, however, it will be appreciated by those of skill in the
relevant arts that application 42 may comprise secure file storage and
retrieval functions, among other things.
Process 134 is requested when electronic mail application 42 wishes to
transmit mail data to a destination via a mail server's data storage
facility. The request identifies an ultimate destination for the mail
data, which may be a different node 26 from requesting node 26 or the same
node. Task 138 verifies authorization for the ultimate destination of the
mail data and identifies a mail server to use for the transmissio | | |
