BACKGROUND [0001] The present description relates to the encryption of one or more encapsulated address components of a data package to thereby facilitate secure communications. SUMMARY [0002] Described herein are systems and techniques by which a transmitting node may utilize a public key value related to an intended recipient to secure at least an encapsulated address component of an outbound communication and by which a receiving gateway may utilize a public key value related to a sender of the communication to authenticate and validate the secured addressed component of the received communication. DESCRIPTION OF THE DRAWINGS [0003] The present description references the following figures. [0004] FIG. I shows network communication nodes, with the nodes Implementing example technologies relating to encapsulating address components. [0005] FIG. 2 shows an example configuration of communications agents and corresponding communications gateways communicating over a network, implementing example technologies relating to encapsulating address components. [0006] FIG. 3 shows an example configuration of a communications gateway, further to the example of FIG. 2. [0007] FIG. 4 shows an example processing flow according to at least one Implementation related to encapsulating address components. DETAILED DESCRIPTION [0008] The present description relating to encapsulating address components may relate to systems, methodologies, techniques, processes, instructions, routines, and tools that may encapsulate one or more address components of a data package in order to facilitate secure communications between a sending node and a receiving node, typically in a network environment. [0009] "Domain," as referenced herein, may refer to, but not be limited to, one or more organizational logical collections of network end points that are capable of implementing network communication that may share a common naming suffix; such devices including, but not limited to, servers, client devices, or other device or various combinations thereof. [0010] "Gateway." as referenced herein, may refer to, but is not limited to, one or more devices that facilitate interaction between two or more domains, networks, or sub-networks. Thus, a gateway may function as either an entry point or an exit point for a respective domain or network. Transport protocol conversion may not be required, but some form of processing is typically performed. [0011] FIG. 1 shows example network environment 100 in which example technologies related to encapsulating address components 105 may be implemented over network 110. In FIG. 1, server devices 115 and 120, client device 125, handheld client device 1 30, and "other" device 1 35 may be communicatively coupled to one another via network 110; and, further, at least one of server devices 11 5 and 120, client device 125, handheld client device 130. and "other" device 135 may be capable of implementing the aforementioned technologies. [0012] Server devices 11 5 and 1 20 may represent devices, such as domain-related receivers or gateways, which are capable of transmitting and receiving electronic packages {e.g., e-mail or audio/video packets) or any other of a variety of data and/or functionality in relation to other devices in network environment 100. Implementations related to encapsulating address components 105 may be applicable to an exchange of electronic packages between server devices 115 and 120 in the clear {Le., without any security measures implemented thereon); although alternative implementations may be applicable even if data to be exchanged is restricted to certain users or only if an appropriate subscription or licensing fee is paid. Server devices 115 and 120 may be at least one of a data package receiver, gateway, mail transport agent (MTA), domain server, network server, application server, blade server, or any combination thereof. Typically, server devices 115 and 120 may represent devices that may be a content source, and client devices 125 and 1 30 may represent any device that may receive such content either via network 11 0 or in an off-line manner. However, according to the example implementations described herein, server devices 115 and 120 and client devices 125 and 130 may Interchangeably be sending nodes or receiving nodes In network environment 100. More particularly, relative to each other, server devices 115 and 120 may interchangeably be a sending node and a receiving node. "Other" device 135 may also be embodied by any of the above examples of server devices 11 5 and 120. [0013] Client device 125 may represent at least one of a variety of known computing devices, including a laptop computer, desktop personal computer (PC), workstation, mainframe computer, Internet appliance, media center, or set-top box that may be associated with network 110 by either a wired or wireless link, and is able to implement example technologies related to encapsulating address components 105. Further, client device 125 may represent the client devices described above in various quantities and/or combinations thereof. "Other" device 1 35 may also be embodied by any of the above examples of client device 125. [0014] Handheld client device 1 30 may represent at least one device that is capable of being associated with network 11 0 by a wireless link, including a mobile (/.e„ cellular) telephone, personal digital assistant (PDA), etc, and is able to implement example technologies related to encapsulating address components 105. Further, handheld device 130 may represent the handheld devices described above in various quantities and/or combinations thereof. "Other" device 135 may also be embodied by any of the above examples of handheld client device 1 30. [0015] "Other" device 135 may represent any further device that is capable of implementing technologies related to encapsulating address components 105 according to one or more of the examples described herein. That is, "other" device 135 may represent any computing or processing device that is capable of at least storing and sharing security information for any other of the devices associated with network 110, and sending or receiving electronic packages {e.g., e-mail or audio/video packets) in relation to any other devices associated with network 110. Thus, "other" device 135 may be a computing or processing device having at least one of an operating system, an interpreter, converter, compiler, or runtime execution environment implemented thereon. These examples are not intended to be limiting in any way, and therefore should not be construed in that manner. [0016] Network 110 may represent any of a variety of conventional network topologies and types, which may Include wired and/or wireless networks. Network 1 10 may further utilize any of a variety of conventional network protocols, including public and/or proprietary protocols. Network 110 may include, for example, the Internet as well at least portions of one or more local area networks (also referred to, individually, as a "LAN"), such as an 802.11 system or, on a larger scale, a wide area network (/,e., WAN"); or a personal area network {i.e., PAN), such as Bluetooth. [0017] FIG. 2 shows example network environment 200 in which communication agents and corresponding communications gateways communicate over network 110, implementing example technologies pertaining to encapsulating address components 105 (see FIG. 1). [0018] Communications gateway A 205 may represent a gateway device, MTA {e,g., SMTP server), receiver, or a combination thereof on domain A 203, Communications gateway A 205 may further be associated with a domain name server having a distributed database as part of the domain naming system (DNS). Communications gateway A 205 may be capable of transmitting and receiving electronic packages {e.g., e-mail or audio/video packets) to other devices, on behalf of agent A 207, over network 11 0. Such transmitting and receiving of messages may be implemented by, e.g., simple mail transfer protocol (SMTP). Further, as part of DNS, communications gateway A 205 may convert requests from programs into IP addresses on domain A 203, and accept requests from other name servers to convert domain names into IP addresses. [0019] Agent A 207 may represent at least one of a variety of known computing devices on domain A 203 capable of transmitting an electronic package {i.e., e-mail or audio/video packets) to one or more nodes on network 110. Such devices may include, but are not limited to, a client device or handheld device. More particularly, agent A 207 may be a source of an electronic package that is intended for a counterpart agent associated with network 110. The electronic packages referenced herein may include e-mail that may or may not have one or more files attached thereto. Such an attached file may include, as non-limiting examples, a text file, an audio file, a video file, a uniform resource locator (URL), etc. Alternative implementations related to encapsulating address components 105 may further contemplate scenarios in which the electronic package to be transmitted is an instant message, a stream of audio packets such as those utilized by voice over IP (VoIP) protocols, or a direct download of electronic packets (I.e., text, audio, video, etc) from an agent in one domain to an agent in another domain or, even further, from one gateway to another as directed by an agent. [0020] Network 11 0, as described above, may represent any of a variety of conventional network topologies and types, which may include wired and/or wireless networks. Network 110 may include, for example, the Internet as well at least portions of one or more LANs, a WAN, or a PAN. [0021] Communications gateway B 210 may be a gateway device, MTA, receiver, or combination thereof on domain B 208. That Is, communications gateway B 210 may be an intended receiving gateway and DNS database counterpart to transmitting communications gateway A 205. [0022] Agen,t B 212, accordingly, may be an intended receiving counterpart to sending agent A 207 from which an electronic package (/.e., e-mail or audio/video packets) may originate. [0023] Encapsulating address components 105, according to at least one example in network environment 200, may incorporate distributed symmetric keys associated with, e.g,, communication that is managed at a high level between domain A 205 and domain B 208 or an alternative communication that is managed more particularly between communications gateway A 205 and communications gateway B 210. Regardless of the example communication scenario, implementations related to encapsulating address components 105 may include each node generating symmetric keys {i.e., a private and a public key value), receiving a public key value from a counterpart node of the respective example pairing either over network 110 or via an out-of-band mechanism, and generating a secret value as a function of the locally generated private key value and the public key value received from the counterpart node. [0024] For example, Implementations related to encapsulating address components 1 05 may include securing an electronic package sent from agent A 207 via communications gateway A 205 using a public key value associated with domain B, in which an intended recipient {i.e., agent B 212) of the electronic package is disposed. The public key value associated with domain B 208 may be more particularly associated communications gateway B 210, agent B 212, or even a user of agent B 21 2. However, the present description, unless otherwise noted, relates to implementations of encapsulating address components 105 using a public key value associated with domain B 208. The symmetric keys associated with domain B 208 are described herein as being generated and stored at communications gateway B 210. However, by one or more alternative implementations, such private/public key pair may be generated and stored at agent B 21 2 or, even further, at a storage device or database that is associated with domain B 208 yet disposed separately on network 110. This description regarding the symmetric keys associated with domain B 208 is applicable, of course, to domain A 203. Further alternative implementations should be obvious in view of the present description, and therefore the examples described herein should not be construed as limiting in any manner. [0025] Thus, according to at least one example implementation related to encapsulating address components 105, symmetric keys are established for both domain A 203 and domain B 208. The public key values corresponding to domain A 203 and domain B 208, respectively, may be stored at communications gateway A 205 and communications gateway B 210- Alternatively, however, such public keys may be stored at a storage device or database that is associated with the respective domains yet disposed separately on network 110. Even further, the public keys may be made available via an out-of-band mechanism. [0026] Additionally, though the implementations related to encapsulating address components 105 are not beholden to a particular transmitting protocol, and therefore no such limitations should be inferred, the present description may contemplate electronic packages being transmitted between domain A 203 and domain B 208 using SMTP (simple mail transfer protocol). [0027] Agent A 207 may be a client device from which an outbound electronic package (i.e., e-mail or audio/video packets) intended for agent B 212 originates. The outbound electronic package may be received at communications gateway A 205, which, similar to agent A 207, may be associated with domain A 203. [0028] Communications gateway A 205 may retrieve a public key value for domain B 208 from communications gateway B 208 or from a storage device associated with domain B 208. Alternative implementations may further contemplate communications gateway A 205 retrieving the public key value for domain B 208 from a local storage device associated with domain A 203. The public key value for domain B 208 may alternatively be retrieved from a DNS database that may or may not be associated with domain B 208 or via an out-of-band mechanism. Further, agent B 212 may not necessarily be the only intended recipient of the outbound electronic package, and therefore communications gateway A 205 may further retrieve a public key value for other domains that are respectively associated with other intended recipients of the outbound electronic package. However, unless otherwise noted, the present description refers to agent B 212 as the sole intended recipient of the electronic package from agent A 207. [0029] Having retrieved the public key value for domain B 208, communications gateway A 205 may utilize the retrieved public key value to encrypt and thereby secure at least one or more encapsulated address components of the outbound electronic package. According to at least one implementation related to encapsulating address components 105, communications gateway A 205 may secure at least the one or more encapsulated address components of the outbound electronic package by using a shared secret generated as a function of a combination of the retrieved public key value and the private component of the locally generated key pair. In light of the keys used to generate the shared secret, shared secrets may alternatively be referred to as a "compiled key" in the present description. [0030] The example implementations related to encapsulating address components 105 described herein contemplate the usage of Diffie-Hellman (alternatively referred to herein as "DH") private/public key pairs. Alternative implementations, therefore, may incorporate such private/public key pairs for elliptical curve Diffie-Hellman (ECDH). Regardless, a DH shared secret (alternatively referred to herein as "DHSS") for domain A 203 may be generated as a function of the private key value for domain A 203 and the retrieved public key value for domain B 208. Further, a DHSS for domain B 208 may be generated as a function of the private key value for domain B 208 and a retrieved public key value for domain A 203. By such examples, the aforementioned DHSS for domain A 203 is the same as the DHSS for domain B 208. That is, by exchanging public keys, the DHSS generated on domain A 203 and domain B 208 are the same even though neither domain is required to export either a private key value or a shared secret value over network 110. Rather, only a public key value is shared from one domain to another, requiring a low level of trust. [0031] However, at least one alternative implementation related to encapsulating address components 105 may utilize a secret value shared among domain A 203 and domain B 208 using the Rivest-Shamir-Adleman (hereafter "RSA") cryptographic protocol. According to at least one such example, a secret value may be generated in association with either domain A 203 or domain B 208 and, if shared, protected by the public key value corresponding to the destination domain. More particularly, to implement the RSA protocol, a public key value may be generated in association with both domain A 203 and domain B 208, though a private key value need be generated in association with only the domain on which the shared secret is to be generated. Thus, for example, a public key value may be generated in association with domain A 203 and for domain B 208; a private key value may be generated in association with domain A 203; a shared secret may be generated in association with domain A 203 as a function of the private key value associated with domain A and the public key value associated with domain B 208; and the shared secret may be protected by the public key value associated with domain B 208 and, further, be retrieved for utilization on domain B 208. [0032] Regardless, after receiving the outbound electronic package, communications gateway A 205 may secure at least one or more encapsulated address components of the outbound electronic package using the shared secret, and transmit, via network 110, the secured outbound electronic package to communications gateway 210 corresponding to intended recipient agent B 212. According to at least one example implementation, a public key value associated with domain A 203 may be attached, or otherwise incorporated in, to the outbound electronic package. For example, a DH public key value associated with domain A 203 may be embedded in an encrypted encapsulated address component (e.g., MAIL FROM). [0033] Communications gateway B 210, upon receiving the secured electronic package, via network 110, may determine domain A 203 to be the source of the electronic package. Thus, communications gateway B 210 may extract a public key value for domain A from the secured electronic package. Alternatively, if the public key value for the domain from which the electronic package is not attached thereto, such public key value may be retrieved from communications gateway A 205 or from storage associated with domain A 203 or a DNS database, [0034] Communications gateway B 210 may utilize the public key value for domain A 203 to re-construct the shared secret [e.g,, DH5S), which may be generated as a function of the private key value for domain B 208 and the public key value for domain B 203. That is, the shared secret generated at domain B 208 is the same as the shared secret generated at domain A 203. [0035] Communications gateway B 210 may utilize the shared secret to decrypt the one or more encapsulated address components of the received electronic package. The encrypted encapsulated address components may pertain to the sender of the electronic package or a receiver of the electronic package. [0036] According to at least one implementation related to encapsulating address components 105, the encapsulated address components may include, but not necessarily be limited to, the "MAIL FROM" portion of a transmitting party's address information and the "RCPT TO" portion of a receiving party's address information. More particularly, an encrypted MAIL FROM may obscure an identity associated with a user or device from which the electronic package originates, but may leave in the clear an identity associated with the domain from which the electronic package originates. Further, an encrypted RCPT TO may obscure an identity associated with a user or device to which an electronic package is intended, but may leave in the clear an identity associated with the domain to which the electronic package may be intended. Thus, in the context of the electronic package being an e-mail message from an originating node associated with sample domain "XX.com" to a receiving node associated with sample domain "YY.com", the MAIL FROM may be identified from the sending address of "MAIL FROM obscured_sender@' XX.com" and the RCPT TO may be identified from a receiving address of "RCPT TO obscured_receiver@ YY.com". In such example, "obscured,sender" and "obscured_receiver" are, respectively, encrypted versions of the real sender username and real receiver username. The implementations related to encapsulating address components 105 is not limited to domains as they pertain to e-mail or packet delivery, of course, and therefore the sample domains described above should not be inferred as limiting. The domains associated with an obscured identity corresponding to a sending or receiving node may further pertain to internet-based telephony and other forms of data exchange. [0037] In the event that the MAIL FROM associated with the electronic package is encrypted, communications gateway B 210 may utilize the shared secret to decrypt the encapsulated address component of the received electronic package, and implement predetermined techniques to authenticate the sender at domain B 208. Further, the shared secret may be used to decrypt the substance of the electronic package In the event that the shared secret was used to encrypt the same at domain A 203. [0038] FIG. 3 shows example configuration 300 of a communications gateway, further to the example of FIG. 2. [0039] In the following description, various operations may be described as being performed by, or otherwise in association with, features described above with reference to FIGS. 1 and 2. Physical and operational features described with respect to configuration 300 may be implemented as hardware, firmware, or software, either singularly or in various combinations together. [0040] Agent 305 may be representative of either agent A 207 or agent B 212 described above with reference to FIG. 2. More particularly, agent 305 may represent a client device capable of originating an electronic package to be transmitted to one or more nodes on network 110 and capable of receiving such an electronic package via a corresponding communications gateway. [0041] Communications gateway 310 may be representative of either transmitting communications gateway A 205 or receiving communications gateway B 210 described above with reference to FIG. 2, and therefore this description of FIG. 3 may refer to communications gateway 310 as transmitting communications gateway 310 or receiving communications gateway 310, depending upon the role thereof. Further, communications agent 310 may represent a gateway device, MTA, or receiver that may or may not be further implemented as a distributed storage system as part of the domain naming system (DNS). [0042] Communications gateway 310 may be capable of transmitting and receiving electronic packages in relation to other devices, particularly other gateways, over network 110. Such transmitting and receiving of messages may be implemented by, e,g,, SMTP. [0043] Further still, a transmitting communications gateway 310 may be capable of accessing a receiving communications gateway 310 or, alternatively, a DNS database to retrieve a corresponding public key value associated with an intended recipient of an electronic package. The retrieved public key value may be associated with a domain corresponding to an intended recipient, a communications gateway corresponding to an intended recipient, a device corresponding to an intended recipient, or even a user who is an intended recipient. However, the present description, unless otherwise noted, relates to transmitting communications gateway 310 accessing and retrieving a public key value associated with a domain corresponding to an intended recipient of an electronic package. [0044] In addition, a transmitting communications gateway 310 may be capable of generating random encryption keys according to various implementations of encapsulating address components 105. More particularly, communications gateway 310, according to at least one example implementation related to encapsulating address components 105 may include one or more of symmetric key {i.e., private/public or "P/P") generator 312, shared secret (SS) generator 313, and encryptor/decryptor (E/D) 314. [0045] P/P generator 31 2 may generate a local P/P key pair for the domain with which communications gateway 310 is associated. Alternatively, the generated P/P key pair may be associated with communications gateway 310, communications agent 305, or even a user of communications agent 305. [0046] S/S generator 313 may generate a shared secret by utilizing the retrieved public key value the local private key value. More particularly, S/S generator 31 3 may generate a DHSS as a function of the private key value produced by P/P generator 312 and the public key value imported from an intended recipient of the electronic package. [0047] E/D 314 nnay encrypt and decrypt, at least, encapsulated address components associated with an electronic package using a shared secret generated by S/S generator 313. E/D 314 may further encrypt portions of an outbound electronic package, including encapsulated address components, by utilizing a symmetric algorithm, in combination with the shared secret. [0048] Storage device 315 may be associated with communications gateway 310 either logically or physically. That is, storage device 315 may be associated with a domain to which communications gateway 310 corresponds without being physically disposed within such domain. More particularly, storage device 315 may be a component of the distributed DNS database corresponding to the domain of communications gateway 310, [0049] Storage device 31 5 may store, in various combinations thereof, one or more public and private encryption key pairs that are generated by P/P generator 312 or are acquired from another source. For example, when associated with receiving communications gateway 310, storage device 315 may store one or more retrieved public key values for a domain corresponding to an intended recipient of an electronic package. Such retrieved public key values may be used to secure encapsulated address components of an electronic package intended for the domain corresponding to the intended recipient thereof. Alternatively, when associated with transmitting communications gateway 310, storage device 315 may store one or more public key values for the domain corresponding to the source of an electronic package. Such retrieved public encryption keys may be used to authorize, validate, and decrypt encapsulated address components of an electronic package. [0050] Regardless of whether communications gateway 310 is a transmitting communications gateway or a receiving communications gateway, storage device 315 may also store therein private key values corresponding to the domain to which communications gateway 310 is associated. That is, in association with domain A 203, storage device 315 may store private key values corresponding to domain A 203, an agent or device associate with domain A 203, or a user associated with domain A 203; and, conversely, in association with domain B 208, storage device 315 may store private key values corresponding to domain B 208, an agent or device associate with domain B 208, or a user associated with domain B 208. [0051] FIC. 4 shows example processing flow 400 according to at least one implementation related to encapsulating address components 105 (see FIG. 1). Various operations described as part of processing flow 400 may be attributed as being performed by, or otherwise in association with, features described above with reference to FIGS. 1 - 3. Such attributions, as well as the operations, are described as examples only, and the operations may be implemented as hardware, firmware, or software, either singularly or in various combinations together. [0052] Processing flow 400 is described below with reference to example implementations A and B. Such implementations are not described in any order of preference, nor are the implementations to be construed as limiting in scope. Rather, the example implementations are provided to illustrate the flexibility and variance enabled by encapsulating address components 105. [0053] EXAMPLE IMPLEMENTATION A [0054] Block 405 may refer to communications gateway A 205 receiving an electronic package {i.e,. e-mail or audio/video packets) from agent A 207 {i.e., client device) for transmittal beyond domain A 203. According to at least one alternative implementation, block 405 may refer to communications gateway A 205 as a content source independent of agent A 207. Regardless, block 405 may refer to at least one intended recipient of the electronic package received at communications gateway A 205 being associated with domain B 208. [0055] Block 410 may refer to communications gateway A 205 retrieving a public key value that is associated with domain B 208. Thus, communications gateway A 205 may access communications gateway B 210, storage device 315, or a DNS server that may or may not be associated with communications gateway B 210, to retrieve a public key value for domain B 208. [0056] Block 415 may refer to communications gateway A 205 encrypting one or more encapsulated address components associated with an outbound electronic package using at least the public key value for domain B 208 as well as a private signing key for domain A 203, which may be stored locally at, or otherwise associated with, domain A 203. [0057] More particularly, block 415 may refer to communications gateway A 205 encrypting at least the MAIL FROM and likely the RCPT TO corresponding to an outbound electronic package using a DHSS generated at, or in association with, communications gateway A 205. [0058] Block 420 may refer to the electronic package having encrypted encapsulated address components being transmitted from communications gateway A 205 to communications gateway B 210 over network 110. Further the electronic pacl