Secure e-mail services system and methods implementing inversion of security control

BACKGROUND OF THE INVENTION

00011. Field of the Invention

0002The present invention is generally related to data security for network transmitted information and, in particular, to systems and methods of securing electronic messages and related content as transmitted between and persistently stored on behalf of users.

00032. Description of the Related Art

0004Information security has and will continue to be one of the most important and, at least as a practical matter, difficult facets of networked computer system management. The widespread distribution and disparate handling of information transmitted between computer systems over communications networks, such as the public Internet and private intranets based on various wired and wireless technologies, introduces many complexities. The immediate transmission and delivery of sensitive information must be secured. The long term storage of the information must also be secured with the specific assurance that the information can be reliably accessed at some later date. The security measures implementing these features, considered from a management reliability perspective, must be unobtrusive to implement, manage, and maintain, both with respect to the computer systems and software involved and the user visible procedures necessary to invoke and use the security controls. A failure at any point results in either a loss of confidence in the ability of the controls to actually establish and maintain security, if not an outright breach of security, or a loss in the ability to recover secured data at some point in the future.

0005Historically, computer information security systems have largely focused on securing point-to-point transmission of data and, more recently, on establishing source controlled security over the delivered information. For point-to-point security, the concern is to prevent the in-transit snooping of sensitive content. In the case of electronic mail (e-mail) and similar message-based communications systems, content within the message, including content logically attached to a message, is at least theoretically exposed during actual transmission. A greater exposure occurs while the message is resident on a store-and-forward network node. Although presumptively transient, the potential vulnerability to snooping and other security attacks persists.

0006Transmission security protocols, such as Secure Sockets Layer (SSL) and the subsequently derived Transport Layer Security (TLS) protocols, provide point-to-point encryption security for network communications. Data packets, collectively representing, for example, an e-mail message and attachments, are automatically encrypted at the source and only unencrypted at the destination. Not only is encryption functionally transparent to the source and destination software and systems, the transmitted information remains encrypted even as transiently stored on computer systems within the transmission path. Inclusion of transmission security protocol support in network operating systems is now widespread.

0007Digital rights management (DRM) systems are characteristic implementations of source managed security over distributed data. In typical implementation, data files are packaged before distribution with the sensitive content encrypted subject to specific certificate-based decryption and use restrictions. A digital rights agent, invoked on a client system requesting access to the content, is required to authenticate the client/user, verify the licensed access rights and establish use controls on the client system. In most instances, use-specific verification of the certificate license is required. Other, somewhat more directly controlled systems, such as shown in U.S. Pat. No. 6,591,367, issued to Korbata et al., rely on a real-time transaction “signal” to qualify use of previously delivered and currently encrypted content on a recipient computer system. Some source controlled security systems, such as shown in U.S. Pat. No. 6,836,846, issued to Kanevsky et al., provide a measure of delegation in evaluating whether a sender defined use restriction is met before allowing access to previously delivered encrypted content. The operation of the digital rights agent, both overall and with respect to a specific DRM secured data file, is enabled and managed by an independent, remote permissions server. This permission server is, in turn, typically controlled by a third-party DRM operator entrusted to manage the DRM security control for many different network distributed data files and licensed users.

0008While formalized and well established, both transmission security protocols and DRM systems represent incomplete or unacceptable approaches for securing network distributed data for at least certain use scenarios. The transmission security protocols are only applicable to data while in transit. Protocol-driven encryption security is automatically stripped once the data reaches a destination computer system, leaving the data then vulnerable. DRM systems quite clearly project security over information as and after delivery. However, long term access to the DRM permissions server cannot be guaranteed. Specifically, DRM-based systems, as well as the systems described in both Korbata and Kanevsky, inherently allow the sender an unconstrained ability to revoke any and all access by a recipient to prior delivered content. While appropriate in defined circumstances, principally involving conventionally licensed proprietary content, the inability of a recipient to ensure future access to properly received, i.e., fully licensed, content is characteristically unacceptable. Functional access to previously received DRM protected content can also be lost as a result of conventional network and server failures, economic or other failure of the DRM operator, or as a consequence of a security breach of the permissions server related systems.

0009Other, source controlled security techniques are known and conventionally used to secure distributed content. These systems, with varying degrees of user-directed automation, utilize encryption to protect the distributed content. In the typical application to e-mail systems, the entire body and any accompanying attachments are block encrypted prior to transmission. The recipient is, in turn, required to execute some user-directed operation to identify an appropriate decryption key and then functionally decrypt the received content.

0010While many different encryption algorithms are available for use, perhaps the most widely used in connection with shared content transmission is public-key encryption. Public-key cryptography is based generation of asymmetric public/private key pairs. A potential recipient, who generates a key pair, maintains the private key secret and publishes the public key for use by potential senders of content to that specific recipient. A recipient may hove, over time if not at the same time, many different published public keys. Content encrypted using a given public key can be decrypted at any time by the recipient using the one corresponding private key. Provided the private key is reliably kept secure, the encrypted content is likewise secure. Decryption without access to the private key, absent a defect in the key generation algorithm, is conventionally considered intractable.

0011To support public key encryption systems in ordinary use, the public keys are published by recipients to various key servers. Both commercial and general availability key servers are accessible on the Internet. A recipient may generate and publish any number of public keys and arbitrarily withdraw or abandon public keys for various reasons. To securely send content to a recipient, at least one currently active recipient public key must be acquired by the sender. Both the sender and receiver must have installed specific version algorithm compatible cryptography engines, typically as adjuncts to their e-mail client programs. Assuming version compatibility, the recipient must locate the specific private key corresponding to the public key used by a sender in order to decrypt content encrypted by a sender.

0012As is evident, these user-directed public key and similar security systems impose a significant managerial and operational burdens. Both the sender and recipient users are required to install and maintain mutually compatible encryption software products. Given the potential for use of different typically third-party software products, assured compatibility can be problematic. Furthermore, the users are required to manage and maintain various key-rings storing the user's own key pairs and the public keys of others. While much can be automated, a significant burden remains on the users to direct publication and acquisition of public keys as desired or needed to allow encrypted content-based communications. Moreover, failure by a recipient user to maintain the private key of a key pair results in loss of access to any and all content that remains encrypted with the corresponding public key. This lack of direct key recoverability, while fundamental to security in the first instance, is a practical limitation in the many circumstances where guaranteed access to secured content is a fundamental business or legal requirement. Alternate approaches to key recoverability, principally involving management schemes for collecting, organizing and storing key pairs, create potential opportunities for security breaches and, in any case, further increase the management burden of maintaining and operating working content security systems.

0013Consequently, a need exists for providing present and future retention of recipient content in a manner that is secure and imposes little operational and managerial burden on both senders and recipients.

SUMMARY OF THE INVENTION

0014Thus, a general purpose of the present invention is to provide a system and methods of receiving and storing content in a secure manner with little imposed operational and managerial burden on users and, further, in a manner fully compatible with networked communications systems.

0015This is achieved in the present invention by providing a secure e-mail service, executable on a recipient e-mail server or associated computer system, that implements inverted security control over recipient content stored by the recipient e-mail server. Recipient content is received in conjunction with e-mail messages transmitted directed to recipients from sender computer systems unassociated with the secure e-mail service. The secure e-mail service includes a policy engine that operates on e-mail messages, as received from a communications network, to evaluate metadata features of the message and select a corresponding encryption key. The service further includes a content processing engine that operates to encrypt a portion of the message in a manner that allows subsequent decryption of said portion using the selected encryption key. A service interface enables transfer of the e-mail message, including the portion as encrypted, to the recipient e-mail server, which supports access by the recipients.

0016An advantage of the present invention is that content received is maintained securely under the control of the recipient in a manner that assures both current and future access to the content.

0017Another advantage of the present invention is that implementations do not require modifications of the system or software utilized by senders, including third-party senders. Recipient client systems and software also do not require modification. In the exemplary case of e-mail systems, recipients can obtain access to secured received content from most any local or remote location using a variety of content accessing devices.

0018A further advantage of the present invention is that system implementation of a secure e-mail service system can be as an external server or as software embedded in an existing server system. Standard networking and system configuration capabilities enable transparent integration of the secure e-mail service, including use of conventional LDAP and Active Directory features.

0019Still another advantage of the present invention is that system implementations can be configured in a variety of manners, corresponding to desired functionality, including as an embedded service, and external shared or hosted server-based service, as an in-line gateway service, and as an auxiliary service capable of supporting unmodified systems providing, in particular, web mail accounts.

0020Yet another advantage of the present invention is that system implementations can support utility operations, including content validation to enable spam and virus checks, content encoding conversion including handling of various sender encryption schemes, and to apply any of a set of localized forms of security encryption.

0021Still another advantage of the present invention is that system implementations can support flexible and selective access delegation, auditing, and secured content recovery capabilities with minimal management requirements essentially transparent to ongoing operation through the use of policy based content handling controls.

BRIEF DESCRIPTION OF THE DRAWINGS

0022<figref idref="DRAWINGS">FIG. 1</figref> is a system block diagram illustrating the architectural implementation of a preferred embodiment of the present invention;

0023<figref idref="DRAWINGS">FIG. 2</figref> presents a simplified block diagram of a preferred embodiment of the present invention demonstrating secure interaction by internal and external users;

0024<figref idref="DRAWINGS">FIG. 3</figref> is functional flow diagram illustrating multiple potential intercept points where a secure content service can be implemented consistent with different preferred embodiments of the present invention;

0025<figref idref="DRAWINGS">FIG. 4</figref> provides a functional flow diagram illustrating a preferred implementation of the present invention supporting Web-based and hosted e-mail accounts;

0026<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram showing a preferred implementation of a secure content service as constructed in accordance with a preferred embodiment of the present invention; and

0027<figref idref="DRAWINGS">FIG. 6</figref> provides a detailed block diagram of a preferred implementation of a content processing engine system as constructed in accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

0028The present invention provides well-defined security control over content, particularly e-mail-based content, for the benefit of recipients and, in preferred implementation, associations or organizations of recipients. In the following detailed description, the invention will be primarily described in terms of preferred e-mail-based embodiments. For convenience, the following terms are defined:

0029Metadata—control information included as part of the envelope, in the context of an e-mail message, or that part of the content of a message that describes or defines features of the e-mail message including, for example, an addressee, the location of a specified content part of the e-mail message, and the encoding of a specified content part of the e-mail message.

0030Sender—a user or, in context, a user computer system that originates an e-mail message.

0031Recipient—a user or, in context, a user computer system that receives an e-mail message.

0032Addressee—the sender designated recipient identified in the envelope metadata of an e-mail message.

0033Mail User Agent (MUA)—a program typically executed on a client computer system that provides for the creation and/or retrieval of an e-mail message by a user. Typically implements the conventional Simple Mail Transport Protocol (SMTP) and Post Office Protocol (POP)/Internet Message Access Protocol (IMAP) client protocols.

0034Mail Submission Agent (MSA)—for the benefit of MUAs that do not implement the SMTP client protocol, a local MSA will operate as an e-mail message receiver providing SMTP client protocol services.

0035Mail Transfer Agent (MTA)—typically, a server program that implements an SMTP server for receiving e-mail messages from MUAs and MSAs.

0036Mail Delivery Agent (MDA)—a server program that operates to deliver e-mail messages to local addressee mailboxes, where the e-mail destination is the local e-mail server system, or to relay the e-mail to another MTA along the route towards the destination e-mail server system.

0037As will be readily apparent to those of ordinary skill in the art, the present invention is equally applicable to other message based communications systems. Therefore, the use of e-mail specific terms in describing the preferred embodiments of the present invention should not be alone interpreted as limiting the scope of the present invention.

0038An architecturally representative environment <b>10</b> generally suitable for employment of the present invention is shown in <figref idref="DRAWINGS">FIG. 1</figref>. For purposes of discussion, like reference numerals are used to designate like parts depicted in one ore more of the figures. As in conventional e-mail distribution environments, various client computer systems and devices <b>12</b>, <b>14</b>, <b>16</b> can, through the public Internet, an intranet, or other communications network <b>18</b>, remotely interoperate with an e-mail server <b>20</b> to send and receive e-mail messages. Other client computer systems and devices <b>22</b>, <b>24</b>, <b>26</b> may also interoperate with the e-mail server <b>20</b> through a local, dedicated network connection <b>28</b>. The e-mail server <b>20</b> will typically implement an MTA/MDA system, such as Microsoft® Windows™ Exchange Server 2003 (www.microsoft.com) or Sendmail™, a product available from Sendmail, Inc. (www.sendmail.org). In typical application, the e-mail server <b>20</b> is supported by a directory access security server <b>30</b>, implementing the Lightweight Directory Access Protocol (LDAP), to provide directory services. In relevant part, LDAP is an established Internet standard protocol that provides user and resource authentication services in response to network directed queries.

0039In a preferred embodiment, the local clients <b>22</b>, <b>24</b>, <b>26</b> are used by members of an organization that is subject to defined requirements for the long-term secured preservation and reliable access to communications received through the e-mail server <b>20</b>. The organization may be formal, such as a corporate entity, or informal, representing only a loosely related community of users. The access and preservation controls imposed may be defined by the organization, individual recipient users, or a combination thereof. Organizationally defined requirements may reflect the need to ensure present and future accessibility to organization owned information and to securely control accessibility to information that the organization becomes responsible for protecting. In particular, the organization may be obligated under legal and contractual requirements to enable independent auditing and to meet the compliance requirements of public laws, such as the Sarbanes-Oxley Act of 2002, and court orders for the production of documents. The remote devices <b>12</b>, <b>14</b>, <b>16</b> may be owned or operated by information senders that are independent or outside of the organization or they may be organization members who are remotely accessing the e-mail server <b>20</b>.

0040In a preferred embodiment, an e-mail security service server <b>32</b> is provided to implement an e-mail security service to establish security control over information provided by senders to some one or more members of the organization served by the e-mail server <b>20</b>. The information is provided as recipient content associated, integrally or by attachment, to an e-mail message transmitted by a sender to a recipient identified as a member of the organization served by the e-mail server <b>20</b>. The e-mail security service may be implemented on a server computer system, such as the server <b>30</b>, separate from the e-mail server <b>20</b> with communication routed through the Internet or intranet <b>18</b> or through a local, secure communications network <b>34</b>. The e-mail security service may also be implemented on the e-mail server <b>20</b>, or on a relaying MTA/MDA server, as a service program executed in conjunction with the existing resident MTA/MDA program.

0041In accordance with the present invention, the e-mail security service, whether implemented on the server <b>32</b> or as a service program executed on another e-mail server <b>20</b>, operates to implement an inversion of security control over recipient content directed to the associated e-mail server <b>20</b>. Inversion of security control is obtained by securing recipient content, typically by encryption, in a manner determined internally by the organization for the benefit of the organization members. Security over the recipient content is thereby established effectively independent of the senders of the content. That is, as implemented in the preferred embodiments, any security measures provided or applied by or on behalf of the senders are removed from the recipient content on receipt and the recipient content is then secured persistently in a manner determined appropriate by the recipient organization.

0042As generally shown in <figref idref="DRAWINGS">FIG. 2</figref>, a system <b>40</b> implementing inversion of security control over recipient content provides for any sender, operating from a remote or otherwise external client system <b>42</b>, to send an e-mail message directed to a recipient user of the e-mail server <b>20</b>. Where a security concern exists for the recipient content sent by e-mail, the sender can ensure transmission security by specifying use of a secure network connection <b>44</b>. Conventional MUAs support specification of a connection using the SSL or TLS protocol for transport transmission of messages and attachments. The sender may further apply sender encryption <b>46</b> to the recipient content to protect the information on the client <b>42</b> pending transmission and, at least by intension, on the e-mail server <b>20</b> after receipt. Various encryption protocol systems, such as Secure Multipurpose Internet Mail Extensions (S/MIME), now maintained by the Internet Engineering Task Force (IETF), and Pretty Good Privacy (PGP; www.pgp.com), can be specified by senders for this purpose.

0043On receipt of an e-mail message, the e-mail server <b>20</b> will automatically remove the security protections provided by the SSL/TLS protocol. To implement inversion of security control, in accordance with the present invention, any applied sender encryption <b>46</b> is also automatically removed by operation of the e-mail security service executed by or on behalf of the secured e-mail server <b>20</b>. The e-mail security service determines, preferably based on policies determined and established by the organization for the benefit of recipients, whether to encrypt <b>48</b> recipient content within the e-mail message and, further, the encryption key or keys that will enable corresponding decryption. The recipient encrypted e-mail message is then stored by the e-mail server <b>20</b> for access by the recipient users. The e-mail security service thereby takes responsibility for the immediate and long-term security of recipient content as persistently stored on the e-mail server <b>20</b> for the benefit of the recipient users of the organization.

0044Recipient users access the e-mail server <b>20</b> using recipient client systems <b>50</b>, which may be local or remote MUA clients of the e-mail server <b>20</b>. The encryption <b>48</b> of the recipient content is preferably encoded into the stored e-mail messages S/MIME in order to be compatible with the operation of conventional MUAs. Retrieved e-mail messages are thereby secured as retrieved by the MUAs, with decryption performed on the client <b>50</b> as the content is presented to the recipient user. Use of a secure network connection <b>52</b> for the retrieval of e-mail messages is not required, but is preferred if only to protect otherwise unencrypted e-mail messages or unencrypted e-mail portions during transport.

0045The present invention is preferably implemented relative to a logical boundary, defining a protected realm, for an organization or association of recipients. The e-mail security service of the present invention can, however, be flexibly architected for use as a gateway, router, or proxy service to suit many different operating scenarios. As generally shown in <figref idref="DRAWINGS">FIG. 3</figref>, an e-mail message, sent by a sender using a MUA client <b>62</b> through a MSA <b>64</b>, will travel through some number of MTAs <b>66</b>, <b>68</b>, before reaching a MDA <b>70</b> capable of delivering the e-mail to an appropriate mailbox within a mailbox store <b>72</b>. As is conventional, the mailbox can be accessed by a recipient using a client MUA <b>74</b> through the services provided by a POP/IMAP daemon <b>76</b>. The e-mail security service <b>78</b> can operate, in accordance with the present invention, as a gateway server that implements or at least appears to be an MTA in the chain of MTAs <b>66</b>, <b>68</b>. As a router, a gateway server can route e-mail messages through the e-mail security service <b>78</b> implemented on a router or server logically internal to the protected realm that again preferably appears to be an MTA in the chain of MTAs <b>66</b>, <b>68</b>. Alternately, an MDA <b>70</b> can employ the e-mail security service <b>78</b> as a back-end or proxy service. To utilize the e-mail security service <b>78</b> as a proxy service, the MDA <b>70</b> internally operates to route received e-mail messages through the e-mail security service <b>78</b>. The presently preferred embodiment is implemented as a plugin service installed on an MTA <b>66</b>, <b>68</b>. In the specific implementation of a Sendmail MTA, the plugin service is supported through the Sendmail Content Management API (Milter).

0046Referring to <figref idref="DRAWINGS">FIG. 4</figref>, a preferred proxy implementation <b>90</b> of the e-mail security service suitable for supporting Web mail MDAs <b>70</b> is shown. E-mail messages from senders are received by the MDA <b>70</b> of a conventional Web mail hosting service <b>92</b> directed to a public mailbox <b>94</b> of an intended recipient. Preferably, the public mailbox <b>94</b> is configured to forward received e-mail messages to an e-mail security server <b>32</b> typically established external to the Web mail hosting service <b>92</b>. The e-mail security service <b>78</b> implemented by the e-mail security server <b>32</b> accesses necessary authentication information and encryption keys provisioned on the directory access security server <b>30</b>, also preferably established external to the Web mail hosting service <b>92</b>. E-mail messages can thereby be autonomously processed through and secured by operation of the e-mail security server <b>32</b>.

0047E-mail messages processed by the e-mail security server <b>32</b> are then returned to an internal or private mailbox also located within the mailbox store <b>72</b> of the Web mail hosting system <b>92</b>. This private mailbox is simply a standard e-mail mailbox having an e-mail address different from that of the public mailbox of the recipient. The typically Web page-based MUA <b>98</b> provided by the Web mail hosting system <b>92</b> and any client MUA <b>74</b>, as executed on a client computer system <b>50</b>, access the private mailbox to read received e-mail messages. Both the Web page-based MUA <b>98</b> and client MUA <b>74</b> have access to the directory access security server <b>30</b> to retrieve encryption keys necessary for reading the content protected by operation of the e-mail security service <b>78</b>. E-mail messages sent using the private e-mail mailbox are, in conventional manner, preferably sent with the appearance of originating from the public mailbox account.

0048Alternative configurations of the proxy implementation <b>90</b> include functionally combining the public and private mailboxes of a recipient. In this case, the forwarding operation of the public mailbox <b>94</b> is set to not forward messages received from the e-mail security server <b>32</b>. In another configuration, the Web mail hosting system <b>92</b> may be operated only as a generic front-end to an existing e-mail system of an organization or association of recipients. In this case, the mailbox store <b>72</b> can be implemented external to the Web mail hosting system <b>92</b>.

0049A preferred implementation of the present invention as a filter <b>110</b> within an MTA <b>112</b> is shown in <figref idref="DRAWINGS">FIG. 5</figref>. Sender e-mail messages are sequentially received through a front-end interface <b>112</b>A of the MTA <b>112</b> and transferred through the filters installed or otherwise registered with the MTA <b>112</b>. In particular, a transport stream filter <b>114</b> consistent with the present invention is provided to intercept e-mail messages. The e-mail messages are routed through policy engine <b>11</b><b>6</b> for analysis, principally involving an examination of the e-mail metadata fields. These metadata fields contain values that will, in defined structured forms, identify the sender and intended recipient or recipients of the e-mail and the location and encoding of potentially multiple content portions of the e-mail message, including attachments. While most metadata fields will be present as part of the e-mail envelope, others may be embedded within the e-mail message.

0050The policy engine <b>116</b> is preferably structured as a rule-based pattern matching engine utilizing a tree-based decision structure to provide flexibility in the design and application of rules. Individual rules may be specified, for example, as applying to one or more particular metadata fields potentially further defined by name, type or location (as part of a message envelope or embedded in the body), to a word or phrase found in the body of an e-mail message or in any one or more metadata fields, to any attachment, or to the entirety of an e-mail message, including attachments. A regular-expression notation is preferably supported to define content matchable by a rule. Thus, by operation of the policy engine <b>116</b>, the e-mail message can be characterized by sender/recipient relations, on the basis of included content and on keywords and phrases included within the e-mail message. In alternate embodiments of the present invention, the rule-based pattern matching engine may be replaced or augmented by a Bayesian-inference engine to enhance the ability to characterize the content of e-mail messages processed through the policy engine <b>116</b>.

0051For the presently preferred embodiments, policy rules are organized in pre-policy, user policy, and post-policy rule groups. This organization allows flexibility in tailoring global and user specific rule sets. Each rule group consists of zero or more rules. When an e-mail message is received, the recipient e-mail address is used to identify the recipient's, or user's, profile including policies to be applied to the message. Multiple rule sets of the same group type may be applied per message per user. That is, within a rule group type, rule sets are preferably organized in a hierarchical structure. For example, a domain hosting service might define a System, Host hierarchy where the System pre-policy is applied first, followed by the Host pre-policy, the user policy, the Host post-policy, and System post-policy.

0052Each rule consists of Conditions and Actions. Multiple actions can be specified in a single rule. Evaluation of rule conditions follow:

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> a) If the evaluation result of a given Condition is TRUE, the associated</entry></row><row><entry>action(s) is(are) carried out. Unless a ”continue” action is specified to</entry></row><row><entry>tell the policy engine to continue with the next rule, the current policy</entry></row><row><entry>processing rule is completed.</entry></row><row><entry> b) Else, the next rule in the current group is processed until all rules</entry></row><row><entry>in the current group are processed.</entry></row><row><entry> c) Else, the first rule in the next group is processed.</entry></row><row><entry>  Each condition is a statement of the form:</entry></row><row><entry> <operand1> [NOT] <operator> <operand2></entry></row><row><entry>  in which:</entry></row><row><entry> <operand1>={From, To, Subject, Body, Sensitivity, Attachment, . . . }</entry></row><row><entry>  a) These are named e-mail metadata fields or other defined</entry></row><row><entry>   structures present as envelope fields or fields embedded</entry></row><row><entry>   within the body of a message</entry></row><row><entry> [NOT]= inverted logic operator; brackets indicate optional use</entry></row><row><entry> <operator>={Contains, Starts With, Ends With, Equals, RegEx,</entry></row><row><entry>  ISENCRYPTED}</entry></row><row><entry>  a) Contains, Starts With, Ends With, Equals are string match</entry></row><row><entry>   operators. RegEx is a regular expression operator</entry></row><row><entry>  b) ISENCRYPTED has no operand. It returns a TRUE if the policy</entry></row><row><entry>   processing so far resulted in an encrypted message. Else, it</entry></row><row><entry>   returns a FALSE.</entry></row><row><entry> <operand2>= ”string match pattern”</entry></row><row><entry>  a) All string operations are non-case sensitive. Multiple conditions</entry></row><row><entry>   in a rule are ANDed together to create a single TRUE or</entry></row><row><entry>   FALSE condition result.</entry></row><row><entry>  Each action is a statement of the form:</entry></row><row><entry> <operator> <operand1> <operand2></entry></row><row><entry>   in which</entry></row><row><entry> <operator>={Encrypt, Prefix, Suffix, Change, Forward, CONTINUE,</entry></row><row><entry>  SETVAR, DELVAR}</entry></row><row><entry>  a) CONTINUE: policy processing is to be continued with the next</entry></row><row><entry>   rule.</entry></row><row><entry>  b) SETVAR <varName> <varValue>: Set (create if it does not exist)</entry></row><row><entry>   variable <varName> with the value <varValue>. The</entry></row><row><entry>   variable only exists for the currently processed message, and</entry></row><row><entry>   the scope is for the entire message. Therefore, a variable set</entry></row><row><entry>   by a pre-policy could be used by anything after the SETVAR</entry></row><row><entry>   statement, which includes the subsequent pre-policy</entry></row><row><entry>   statement, the user's policy, and the post-policy.</entry></row><row><entry>  c) DELVAR <varName>: Delete the variable <varName>.</entry></row><row><entry> <operand1>, <operand2>: depending on the action, there might be one</entry></row><row><entry>  or more operands used to specify the effect of the operation.</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0053For example, to implement a basic configuration for selective security protection, a recipient may specify a first e-mail address for receipt of ordinary content, such as personal, non-business, and a second e-mail address for sensitive content. While the two e-mail addresses may and preferably are aliased to the same mailbox by the MDA <b>70</b>, the policy engine <b>116</b> operating at the level of an MTA <b>66</b>, <b>68</b> in the path of both e-mail addresses recognizes the distinction in the “To” metadata fields, passes through e-mail directed to the first address and substantively processes e-mail directed to the second address. Alternately, the policy engine may be established only in the routed path of the second address.

0054To selectively secure sensitive e-mail received through a Web or other third-party e-mail hosting system, the forwarding agent of the hosting system should be set to forward received e-mail messages to an e-mail address routed through an e-mail security server <b>32</b>. The forwarding agent should also be configured to delete any local copy of the e-mail forwarded. Finally, the forwarding agent should be set to accept without forwarding e-mail received from the e-mail security server <b>32</b>. The policy rules implemented on the e-mail security service <b>78</b> of the e-mail security server <b>32</b> will determine whether specific e-mail instances are secured.

0055To selectively secure an entire e-mail domain, or security realm, the domain name service (DNS) mail exchanger (MX) record is preferably set to point to the e-mail security server <b>32</b>. Consequently, all e-mail messages to the protected realm route through the e-mail security server <b>32</b> and are subject to policy processing.

0056A simplified example of a rule set is provided in Table 1:

0000<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="133pt" align="center" /><colspec colname="2" colwidth="84pt" align="center" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Rule Condition</entry><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="28pt" align="center" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="35pt" align="left" /><colspec colname="4" colwidth="42pt" align="left" /><colspec colname="5" colwidth="84pt" align="left" /><tbody valign="top"><row><entry>Rule</entry><entry>Field</entry><entry>Operator</entry><entry>Text</entry><entry>Rule Action(s)</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>1</entry><entry>subject</entry><entry>contains</entry><entry>Acquisition</entry><entry>Change [Subject] to</entry></row><row><entry /><entry /><entry /><entry /><entry>“Discussion”</entry></row><row><entry /><entry /><entry /><entry /><entry>Add [Cc] Proj83 group</entry></row><row><entry /><entry /><entry /><entry /><entry>Encrypt [Body] with</entry></row><row><entry /><entry /><entry /><entry /><entry>“_myKey”</entry></row><row><entry /><entry /><entry /><entry /><entry>Encrypt [Attachment]</entry></row><row><entry /><entry /><entry /><entry /><entry>with “_myKey”</entry></row><row><entry /><entry /><entry /><entry /><entry>Encrypt [Body] with</entry></row><row><entry /><entry /><entry /><entry /><entry>“_proj83”</entry></row><row><entry /><entry /><entry /><entry /><entry>Encrypt [Attachment] with</entry></row><row><entry /><entry /><entry /><entry /><entry>“_proj83”</entry></row><row><entry>2</entry><entry>subject</entry><entry>contains</entry><entry>BOD</entry><entry>Encrypt [Body] with</entry></row><row><entry /><entry /><entry /><entry /><entry>“_myKey”</entry></row><row><entry /><entry /><entry /><entry /><entry>Encrypt [Body] with</entry></row><row><entry /><entry /><entry /><entry /><entry>“_audit01”</entry></row><row><entry>3</entry><entry>from</entry><entry>contains</entry><entry>myCorp.com</entry><entry>Encrypt [Body] with</entry></row><row><entry /><entry /><entry /><entry /><entry>“_myKey”</entry></row><row><entry>4</entry><entry /><entry /><entry /><entry>Encrypt [Body] with</entry></row><row><entry /><entry /><entry /><entry /><entry>“_myKey”</entry></row><row><entry /><entry /><entry /><entry /><entry>Encrypt [Body] with</entry></row><row><entry /><entry /><entry /><entry /><entry>“admin32”</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry namest="1" nameend="5" align="left" id="FOO-00001">Where:</entry></row><row><entry namest="1" nameend="5" align="left" id="FOO-00002">Rule 1 specifies that if the e-mail subject field contains the word “Acquisition”, then change it to “Discussion”, and encrypt both the body of the message and any attachments using keys identified by “_myKey” and “_proj83”. The e-mail is also copied to the members of a defined “Proj83” e-mail group. In typical implementation, the “_myKey” key is associateduniquely with the e-mail recipient while the “_proj83” key is added to allow content access by the members of the corresponding project group.</entry></row><row><entry namest="1" nameend="5" align="left" id="FOO-00003">Rule 2: specifies that if the e-mail subject field contains the word “BOD”, encrypt the body using a key identified by “_myKey”. The word “BOD” is used for all emails that are related to the Board of Directors. Rule 2 also allows the e-mail to be independently accessible by the members of a corporate audit group having access authority to the key designated “audit01”.</entry></row><row><entry namest="1" nameend="5" align="left" id="FOO-00004">Rule 3: all emails coming from the domain myCorp.com are encrypted exclusively using a key identified by “_myKey”.</entry></row><row><entry namest="1" nameend="5" align="left" id="FOO-00005">Rule 4: for all other emails, encrypt the body using keys identified by “_myKey” and “admin32”. Rule 4 thus demonstrates access delegation by enabling a designated support staff administrator, or group of administrators, authorized to use the “admin32” key to access this e-mail content even where they are not a recipient.</entry></row></tbody></tgroup></table></tables>

0057Policy rules are retrieved through a policy retrieval service <b>118</b> from a persistent policy store <b>120</b> on initialization of the policy engine <b>116</b>. Preferably, rules are retrieved, on demand, from the store <b>120</b> dependent on the progression of rule evaluation required by the policy engine <b>116</b>. In typical implementation, policy rules are cached in memory for subsequent use.

0058The policy engine evaluation of rules applicable to a particular message define the policy actions to be implemented by a content processing engine <b>122</b>. These actions, presented as actionable policy statements, are presented to the content processing engine <b>122</b> concurrent with the e-mail message, including attached content. Consistent with the preferred rule definitions provided above, the actionable policy statements are used by the content processing engine <b>122</b> to determine rewriting of the e-mail message metadata, including addition of e-mail metadata fields arid values, encryption of different selected content portions of the e-mail message, including attachments, and the selection of the keys that will be permitted to enable decryption of the different encrypted content portions of the e-mail message. Thus, for example, a policy statement can direct existing recipient names be rewritten, singularly or in combination, to add or complete the content of other metadata fields, such as add additional “bcc” recipient names. Other policy statements can specify that discrete portions of the body be encrypted and corresponding S/MIME, or equivalent, metodata fields be added to the body respectively referencing the encrypted portions. Additional policy statements can specify, for each encrypted portion, one or more encryption keys to be associated with that portion to authenticate the decryption of that encrypted portion of the e-mail message. The content processing engine <b>122</b> operates to functionally implement these policy statements operating on the data stream representing the e-mail message, including attachments. Encryption keys referenced by the policy statements are obtained through a key retrieval service <b>124</b> from a persistent, secure key store <b>96</b>. For the preferred embodiments of the present invention, the key retrieval service <b>124</b> and persistent store <b>96</b> are implemented by the directory access security server <b>30</b>.

0059The e-mail message, as modified by the content processing engine <b>122</b>, is returned to the transport stream filter <b>114</b> to complete processing through the MTA completion stage <b>112</b>B of the MTA <b>112</b>. In accordance with the present invention, at least the minimum required envelope metadata fields remain presented in conventional form. Thus, the operation of the present invention is essentially transparent to the normal function of the MTA <b>112</b>, other MTAs <b>66</b>, <b>68</b>, MDA <b>70</b>, and client MUAs <b>74</b>.

0060In accordance with the present invention, the content processing engine <b>122</b> preferably provides for the removal of persistent security controls applied by or on behalf of the sender. Initial removal of source applied encryption is desired to enable conversion to recipient controlled security, i.e., inverted security control, and to allow selected clear text possessing of the received content. Removal of Source encrypted content can be skipped where the source applied encryption is effectively determined by the recipient, such as through requiring senders to use only a recipient specified encryption key and algorithm, no additional encryption keys need be added on receipt (or can be added to the envelope set of encryption keys with re-encryption), and no clear text processing of the content is required.

0061Source encryption applied by use of an SSL/TLS protocol for transmission will be removed automatically by the server system hosting the security service of the present invention. PGP-based or other sender encryption will remain, though properly identified by an S/MIME or equivalent metadata field associated with the encrypted block of content. As shown in <figref idref="DRAWINGS">FIG. 6</figref>, a sender decryption engine <b>132</b> is preferably provided as an adjunct to the content processing engine <b>122</b>. The sender decryption engine <b>132</b> preferably implements a full complement of the S/MIME compatible decryption algorithms and other and other de-facto standard decryption algorithms, such as PGP.

0062A sender key retrieval service <b>134</b> is preferably provided to support operation of the content processing engine <b>122</b>. In typical implementation, the sender key retrieval service <b>134</b> obtains, from a local secure key store or remote directory access security server <b>30</b>, the private keys needed by the sender decryption engine <b>132</b> to decrypt the secured content of received e-mail messages. For encrypted content parts marked by a S/MIME metadata field, the content processing engine <b>122</b> preferably directly identifies and directs key retrieval and decryption. Where a content part is not identified explicitly by a standard metadata field, the content processing engine <b>122</b> can operate to identify the encryption algorithm from, for example, characteristics of the encrypted content part, such as embedded headers and the attachment filename suffix. If not directly determinable from the associated metadata field, the likely identity of the public encryption key can be determined from analysis, for example, of the sender, recipient, subject, and other metadata fields, and characterization of the unencrypted body text. Once identified, the corresponding private encryption key can then be retrieved for use by the sender decryption engine <b>132</b>.

0063The processing of clear text content is preferably performed by a content conversion engine <b>138</b> under the control of the content processing engine <b>122</b>. In typical implementation, the content conversion engine <b>138</b> can implement a filter interface, allowing hosting of other existing filters of defined function requiring content access, such as conventional filters for unsolicited bulk e-mail (UBE) and unsolicited commercial e-mail (UCE), both colloquially referred to as spam, and virus detection filters. These hosted filters can operate to characterize the body of an e-mail message, such as through the addition of a spam rating header, or to modify the message, such as by removal of viral code and attachments.

0064The content conversion engine <b>138</b> can also perform formatting and translating conversions of content from one identified form to another. For example, a policy rule, realized as an actionable policy statement, may specify that certain content types, such as images, embedded in the body of a message are to be converted into external attachments. In such a case, the content conversion engine <b>1</b><b>38</b> operates to reformat the e-mail message to present images as external attachments. Other policy rules may be used to specify content-type identified blocks of content be converted to a different given type. The present invention recognizes that the many existing proprietary data formats, though common in the short term, may not be reliably accessible over the long term. In many cases, a reasonably equivalent file format is known and may be perceived by a recipient or organization as more likely to be accessible well into the future. In response to an actionable policy statement, a content block of defined content type is converted by the content conversion engine <b>138</b> to a given survivor content type. Thus, for example, graphics formats considered likely to become marginal, if not orphaned, are by policy converted automatically into a perceived survivor format, such as JPEG or PDF. Document formats can also be converted to a chosen survivor document or image format. Even where format obsolescence is not a concern, an established policy of, for example, converging related formats to a single archival standard for an organization can be supported by the content conversion engine <b>138</b>.

0065Once sender applied encryption is removed and applicable content conversions are applied, the content processing engine <b>122</b> utilizes a local encryption engine <b>136</b> to re-encrypt selected content portions of the e-mail message and attachments. The portions selected typically include those that were subject to sender applied encryption. In accordance with the present invention, however, the final selection of content portions that will be subject to locally applied encryption is determined by the policy engine <b>116</b>. That is, that a content portion is subject to sender applied encryption can be recognized, by rule, and functionally considered in conjunction with, for example, the sender and recipient names and the characterization of the content in determining whether local encryption is to be applied.

0066Thus, a system and methods for implementing an inversion of security control over recipient content has been described. While the present invention has been described particularly with reference to e-mail message-based systems, the present invention is particularly applicable to other messaging systems, including Internet messaging (IM) systems, message based content distribution systems, and voice over IP (VOIP) systems.

0067In view of the above description of the preferred embodiments of the present invention, many modifications and variations of the disclosed embodiments will be readily appreciated by those of skill in the art. It is therefore to be understood that, within the scope of the appended claims, the invention may be practiced otherwise than as specifically described above.