KR102880532B1 - Registered encrypted electronic messages and revised response system - Google Patents

Abstract

A system for processing received emails having modified content, and/or wherein the message content is reformatted, encrypted and cryptographically recorded, the message headers are parsed to determine a security level of the message, the security level is stored in a database, and the secured and/or modified message is delivered to the intended recipient.

Description

Registered encrypted electronic messages and revised response system

Cross-reference to related applications

This application claims priority to previously filed U.S. Provisional Application No. 62/833,022, filed April 12, 2019, entitled “Preventing Accidental Disclosure of Sensitive Message Portions in Confirmation and Reply to Encrypted Electronic Message Transmission,” which is incorporated herein by reference in its entirety.

Technology field

This disclosure relates to electronic message security within the category of private delivery of electronic messages and the subcategory of privacy compliance. More specifically, the disclosure relates to electronic message security within the category of private delivery of electronic messages and the subcategory of privacy compliance in that it protects a sender or a sending organization from claims of a data breach arising from claims that a sent message was not transmitted in a secure manner from a privacy perspective; and, in the case of a data privacy compliance audit, it provides audit-ready records to verify the secure delivery of electronic messages.

Mail took on an electronic form in 1965 and was given the name "e-mail." It began as a way for multiple users of time-sharing mainframe computers to communicate with each other. It quickly expanded into "network e-mail," allowing users to send messages between different computers by at least 1966. Today, e-mail is a simple communication tool that can be used regardless of an individual's level of technical knowledge or understanding of how e-mail works.

Today, email (an electronic messaging system and protocol) is often relied upon for important communications between people and is used to transmit sensitive financial, health-related, strategic, or legal information or to direct actions that the sender may not want made available to parties other than the email recipient.

Many states, countries, and industries have regulations requiring the sender of certain information to use systems that transmit electronic messages in a more private manner than standard email. One example is the US Health Insurance Portability Accountability Act (HIPAA) of 1996, which provides data privacy and security provisions for protecting health information. Another example is the European General Data Protection Regulation (GDPR), which includes regulations for email privacy compliance. The GDPR defines what compliance must achieve rather than how to meet the requirements. Consequently, while it does not specify a specific method of email encryption, it does require that consumers and personal information handlers maintain the privacy of their information and demonstrate compliance with privacy requirements. These requirements are detailed in Articles 5, 1(f), 2, and 32, 1(a), 1(d) of the GDPR, which focus on protecting personal data during transmission, along with the ability to demonstrate that personal data has been protected.

While typical email and electronic messaging system users know how to send, receive, read, reply to, and forward electronic messages (email refers to any electronic message transmitted using the Electronic Message Transfer Protocol), typical email users don't know how to transmit email in a more secure or private manner, or how to verify that a message was sent using a more secure or private method than standard email. When receiving email, typical email users don't know how to verify that it was received using secure or encrypted transmission. They don't know how to protect recipients from receiving content sent via secure transmission and from exposing or insecurely responding to potentially unsent content within the email thread.

Advanced email users can configure their email programs to automatically filter emails, place them in special folders, or mark emails with varying levels of importance. Advanced email users can also configure their systems to deliver email in a more personalized way than standard email delivery; standard email delivery is defined as electronic message delivery using a combination of protocols such as SMTP, ESMTP, SMS, SMPP, MMS, HTTP, HTTPS, and SSL/TLS.

Some email users or their email operators may install third-party programs or encryption keys within their existing email programs to help address various known and common security threats associated with email. Users (senders and/or recipients of email) or email system administrators may add or configure software within their email servers, email gateways, or email user interfaces (commonly referred to as "email clients"). These add-on software programs may provide options for sending messages in a more private manner than using standard messaging protocols. Some users may choose to upload messages to a secure server, which sends links to retrieve or view messages, while others may choose to compose messages in a secure program securely accessed via a web browser and then send them. Some systems may use secure application programming interfaces, including protocols such as SOAP, REST, and EDI interchange protocols.

There are various ways to send messages more privately than using standard email transport protocols. Some of these methods use PGP, PKI, AES 256-bit, PDF, Link Retrieval, HTML Wrapper, and others, with or without secure connections like TLS, SSL, or HTTPS. Secure messaging systems, including EDI, SMS, and MMS, also use other protocols.

What is needed is a means for a sender or sending agency, or for a receiver, or for a receiver replying to a sender, to (1) ensure private transmission from a sending point to a receiving point (where the sending end and the receiving end may be different in different circumstances), (2) record the fact of end-to-end private transmission, (3) provide means for third-party verification of the fact of end-to-end private transmission on a per-message basis, and (4) modify and optionally further record the message content or portions of the message content based on a recipient reply (e.g., to ensure that the recipient reply does not transmit private information specified in the recipient reply). The present invention satisfies these and other needs.

In its most general aspect, the present disclosure provides systems and methods for protecting a sender or a sending organization from potential violations of information privacy policies that require that a particular message or portion of a message be transmitted in an encrypted manner or in a manner that minimizes the likelihood of accidental disclosure of personal information. In another aspect, the present disclosure provides systems and methods for protecting a sender or a sending organization from a third-party claim that a message or portion of a message was not transmitted in an encrypted manner.

In another aspect, the present disclosure describes systems and methods that provide proof of authenticity and visibility to the sender or sender organization of encrypted delivery, and proof of authenticity and visibility of receipt of inbound messages sent using encrypted delivery from the sender or sender agent, for peace of mind or protection in the event of a privacy compliance audit. In one exemplary aspect, a sender may be protected when a receiver receives a message using a secure message transfer process that allows the receiver to respond to a message that potentially exposes the original message content if the message is returned without a secure transfer process.

In another aspect, the present disclosure provides audit-ready records to verify the secure delivery of electronic messages, enabling better management of message policies and providing readily accessible information for data privacy compliance audits. In one aspect, the present disclosure provides that the systems and methods described herein may be implemented individually, partially, or in three parts, which may be implemented together.

In another aspect, the present disclosure provides a record of the fact of encrypted transmission of an electronic message from one end to a receiving end, to a sender or a sending organization (or a receiver or a receiving response). In another aspect, the present disclosure further provides for generating a record containing sufficient information related to an individual transmission to be relied upon as evidence of the encrypted transmission.

In another aspect, the present disclosure provides a means for a third party to authenticate a record of a private transmission. In another aspect, the present disclosure generates a record that provides the sender of the message with an opportunity to respond to the returned message in a more private manner (without exposing any or all of the original information or content of the sender's message, if included in the response message thread).

In another aspect, the present disclosure provides a means for a sender or a third party to authenticate a record of the fact that certain transmitted content has been modified or removed from a recipient's response message thread.

In another aspect, the present disclosure provides a system for providing a modified response service for an email message, the system comprising a server remote from a recipient, the server being programmed to: receive a message including content marked by the sender for modification, determine whether any settings set by the sender of the message are to be used in processing the received message, remove the content marked for modification based on the determined settings, reformat the message based on the determined settings, and transmit the reformatted message and information related to the removed content to the recipient. In another aspect, the server is further programmed to store the removed content in a database stored in memory. In yet another aspect, the server is programmed to add viewing restrictions to the removed content to limit various parameters associated with viewing the stored removed content. In another aspect, the transmitted information associated with the removed content is a link providing access to the removed content stored in the database.

In another aspect, the server is further programmed to add a link to the transmitted reformatted message that includes response control information that limits the content that a response message based on the transmitted reformatted message can contain. In one aspect, the control information protects the response from including information associated with the removed content. In another aspect, the control information includes information set by the sender.

In another aspect, the present disclosure provides a system for providing a registered encryption service for an email system, the system comprising a server remote from the recipient that is programmed to receive a message from a sender, parse one or more headers of the received message, store information associated with the one or more parsed headers in a database according to a security level or other data provided by the sender, secure the received message for transmission to an intended recipient, transmit the secured message and information associated with the secured message, process the information stored in the database to determine a security level of the message, and generate a report regarding the transmitted secured message that includes an indication of the determined security level. In one aspect, the generated report is an authentication-ready report. In another aspect, the authentication-ready report is transmitted to the sender.

In another aspect, the server is further programmed to store a record of the method used to secure the received message in a database stored in memory. In another aspect, the server is further programmed to store a record containing a portion of the transmission protocol used to transmit the secured message to the recipient in a database stored in memory. In another aspect, the server is further programmed to store a record of the method used to secure the message transmitted to the recipient in a database stored in memory. In another aspect, the server is further programmed to store a record of the method used by the sender or the sender server to secure the message received from the sender and the method used to secure the message transmitted to the recipient in a database stored in memory. In another aspect, the server is further programmed to record the activation of content modification from the message transmitted to the recipient.

Other features and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which illustrate by way of example the principles of the present invention.

The following detailed descriptions and examples are provided for the purpose of non-exhaustive description of some, but not all, examples or embodiments of the present disclosure and are not intended to limit the scope of the present disclosure in any way.
FIG. 1 is a schematic diagram of a computer or processing system that can be specifically modified by various embodiments of the present disclosure to perform registered modification or registered encryption of a message transmitted from a sender to a recipient over a network.
FIG. 2 is a schematic diagram of a network used according to various embodiments of the present disclosure.
Figure 3 graphically represents the results of a survey asking customers why they use email encryption.
Figure 4 graphically represents the results of a survey asking customers to rank the importance of features in an email encryption service.
Figure 5 is a schematic diagram of one embodiment of a process for determining an acceptable level of encryption that can be received by a recipient of an electronic message.
FIG. 6 illustrates exemplary sender settings used in accordance with various embodiments of the present disclosure.
Figure 7 is a schematic diagram of one embodiment of a system according to the present disclosure.
Figure 8 is a schematic diagram of one aspect of the embodiment of Figure 7.
Figure 9 is a schematic diagram of one aspect of the embodiment of Figure 8.
Figure 10 is a schematic diagram of one aspect of the embodiment of Figure 7.
Figure 11 is a schematic diagram of one aspect of the embodiment of Figure 7.
Figure 12 is a schematic diagram of one aspect of the embodiment of Figure 11.
Fig. 13 is a schematic diagram of one aspect of the embodiment of Fig. 11.
Fig. 14 is a schematic diagram of one aspect of the embodiment of Fig. 11.
Fig. 15 is a schematic diagram of one aspect of the embodiment of Fig. 11.
FIG. 16 is a schematic diagram of an embodiment of the present disclosure illustrating processing of a response transmitted from a recipient of a message of the embodiment of FIG. 7.
FIG. 17 is a graphical representation of a menu for sender settings according to various embodiments of the present disclosure.
FIG. 18 is a graphical drawing of a menu used in a system according to various embodiments of the present disclosure.
FIG. 19 is a graphical illustration of exemplary screen shots illustrating features of various embodiments of the present disclosure.
FIG. 20 is a flowchart illustrating steps of a modified response embodiment of the present disclosure.
FIG. 21 is a schematic diagram of one registered encryption embodiment of the present disclosure.
Fig. 22 is a schematic diagram of one aspect of the embodiment of Fig. 21.
Figure 23 is a schematic diagram of one aspect of the embodiment of Figure 21.
Figure 24 is a graphical representation of a report generated according to the present disclosure.
Figure 25 is a graphical representation of a report generated according to the present disclosure.
FIG. 26 is a flowchart illustrating various steps of an embodiment of a registered encryption process according to the present disclosure.
Figure 27 is a block diagram illustrating the arrangement of an electronic message header portion.

Mail took on an electronic form in 1965 and was given the name "e-mail." It began as a way for multiple users of time-sharing mainframe computers to communicate with each other. It quickly expanded into "network e-mail," allowing users to send messages between different computers by at least 1966. Today, e-mail is a simple communication tool that can be used regardless of an individual's level of technical knowledge or understanding of how e-mail works.

Today, email (an electronic messaging system and protocol) is often relied upon for important communications between people and is used to transmit sensitive financial, health-related, strategic, or legal information or to direct actions that the sender may not want made available to parties other than the email recipient.

Many states, countries, and industries have regulations requiring the sender of certain information to use systems that transmit electronic messages in a more private manner than standard email. One example is the US Health Insurance Portability Accountability Act (HIPAA) of 1996, which provides data privacy and security provisions for protecting health information. Another example is the European General Data Protection Regulation (GDPR), which includes regulations for email privacy compliance. The GDPR defines what compliance must achieve rather than how to meet the requirements. Consequently, while it does not specify a specific method of email encryption, it does require that consumers and personal information handlers maintain the privacy of their information and demonstrate compliance with privacy requirements. These requirements are detailed in Articles 5, 1(f), 2, and 32, 1(a), 1(d) of the GDPR, which focus on protecting personal data during transmission, along with the ability to demonstrate that personal data has been protected.

While typical email and electronic messaging system users know how to send, receive, read, reply to, and forward electronic messages (email refers to any electronic message transmitted using the Electronic Message Transfer Protocol), typical email users don't know how to transmit email in a more secure or private manner, or how to verify that a message was sent using a more secure or private method than standard email. Upon receiving an email, typical email users don't know how to verify that it was received using secure or encrypted transmission. They don't know how to protect recipients from receiving content sent using secure transmission and from exposing or insecurely responding to potentially unseen content within the email thread.

Advanced email users can configure their email programs to automatically filter emails, place them in special folders, or mark emails with varying levels of importance. Advanced email users can also configure their systems to deliver email in a more personalized way than standard email delivery; standard email delivery is defined as electronic message delivery using a combination of protocols such as SMTP, ESMTP, SMS, SMPP, MMS, HTTP, HTTPS, and SSL/TLS.

Some email users or their email operators may install third-party programs or encryption keys within their existing email programs to help address various known and common security threats associated with email. Users (senders and/or recipients of email) or email system administrators may add or configure software within their email servers, email gateways, or email user interfaces (commonly referred to as "email clients"). These add-on software programs may provide options for sending messages in a more private manner than using standard messaging protocols. Some users may choose to upload messages to a secure server, which sends links to retrieve or view messages, while others may choose to compose messages in a secure program securely accessed via a web browser and then send them. Some systems may use secure application programming interfaces, including protocols such as SOAP, REST, and EDI interchange protocols.

There are various ways to send messages more privately than using standard email transport protocols. Some of these methods use PGP, PKI, AES 256-bit, PDF, link search, HTML wrappers, and others, with or without secure connections like TLS, SSL, or HTTPS. Secure messaging systems, including EDI, SMS, and MMS, also use other protocols.

Some common methods for encrypting electronic message transmissions are summarized as follows:

A. PKI: The exchange of public encryption keys generated by the sender and receiver's digital certificates before sending a message. These "keys" are often stored in the Microsoft Outlook program. To use them, both the sender and receiver typically need a full desktop installation of Microsoft Outlook or an advanced email program such as Lotus Notes; this typically does not include Gmail, Outlook.com, or a web email program.

B. PGP: Exchange of keys generated by the sender and recipient. Typically, the sender and recipient need an email program configured to handle key exchange or manage the level of sophistication between users to handle this type of encryption. Some services attempt to make this easier.

C. PDF: AES 128-bit or 256-bit PDF encryption. Here, the message is printed in PDF format, attachments are included in their native format, and the PDF serves as an encrypted wrapper for the message body and all attachments. The encrypted PDF file is attached to the email delivered to the recipient, and the message remains encrypted within the recipient's inbox while contained within the encrypted PDF file attachment.

D. Transport Layer Security (TLS): Transport Layer Security (TLS) connects a sender server to a recipient server via a secure, encrypted transmission. This means that only messages to the recipient server are secured, and the recipient server must be configured to operate with this option (which is not ubiquitous or reliable). Furthermore, there are various iterations of TLS, starting with the Secure Sockets Layer (SSL) protocol, TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 and later.

E. Link Retrieval: A store-and-forward system where the sender sends an email, which is then stored on an intermediate server. The intermediate server then sends an email containing a link for retrieving the message. The link often requires the recipient to sign up for an account and complete several necessary steps to view and download the sent message. This requires a third party to store the message while the recipient completes the download and retrieval steps.

F. HTML Wrapper: The sender sends an email, which is stored on an intermediate server. The intermediate server then sends the email with an HTML file attached. The HTML file is large because the message and all attachments are encrypted. When the recipient clicks the HTML file, they are often taken to a webpage where they sign up for an account. After a few necessary steps, the message is transmitted from the recipient (from the HTML wrapper file) back to the sending server (or intermediate server), where it is then displayed in a browser, allowing the recipient to view and download the original message.

G. File Sharing: A system whereby a user/sender uploads a document to an online storage area and then grants recipients access to the online folder to view and download files frequently, with the necessary recipient password or account access rights.

The above method of transmitting electronic messages in a more secure manner than standard email messages is a brief summary of the various methods used and is not intended to be a complete description of any one protocol or method, as there are other methods that may be used.

With growing awareness of information privacy violations and concerns about protecting sensitive, nonpublic consumer information, regulators have created privacy regulations that require senders or sending organizations to use transmission methods that protect transmitted information from accidental disclosure to unintended recipients, eavesdroppers, or Internet thieves.

These regulations do not typically specify a specific method of transmission, but generally state that methods must be used to ensure the privacy of transmitted information, and some require that audit-ready records be maintained to demonstrate the methods used to ensure the privacy of transmitted information.

One of the major federal data privacy regulations in the United States is HIPAA. In Europe, the General Data Protection Regulation (GDPR), Regulation (EU) 2016/679, goes further, emphasizing the importance of "proof of data privacy compliance"—automated and verifiable evidence at the message level (as described in Articles 5(1) & 2 and 32(1) of the GDPR)—since accountability is a key requirement of the GDPR directive. US state regulators and legislators outside of Europe are adopting new privacy regulations modeled after the European GDPR.

Due to regulations, businesses handling increasingly consumer information must not only securely transmit information but also maintain auditable evidence of compliance and secure email delivery. For many companies, the new requirements will require a complete overhaul of their email encryption services. Auditable evidence of encryption compliance will be essential to address compliance audits and potential data breaches, especially when the penalties are as steep as those stipulated by regulators.

As internet eavesdroppers and criminals become more sophisticated, their ability to micro-target users or companies, and their ability to handle confidential or regulated personal information (such as healthcare or financial information), requires businesses to not only securely transmit information but also maintain visibility and tracking to ensure that systems designed to transmit information more securely actually transmit messages as secure email delivery; they must also maintain auditable evidence of compliant secure delivery. Users, like compliance officers and system administrators, will want visibility into the encrypted delivery, receipt, or modification of sensitive content. For many businesses, the new requirements will require a complete overhaul of their email encryption services. Auditable evidence of encryption compliance will be necessary to handle compliance audits and potential data breaches, especially when fines are as steep as those announced by regulators.

Key industries targeted include those handling third-party consumer financial or health information. Typically, these include companies engaged in consumer healthcare and financial services (banking, lending, investment advisory, insurance, residential real estate, etc.), as well as functional areas such as human resources, finance, accounting, and customer service. Furthermore, attorneys should be concerned about the ability to redact content from email responses, as this protects against the disclosure of sensitive information and is often associated with the term "redactment" due to its widespread use in document editing.

In particular, parts of the GDPR emphasize the importance of maintaining records of encrypted transmissions: Article 5 on security, confidentiality and accountability, and Article 32 on evaluating the effectiveness of technical measures to ensure security and encryption.

Article 5(1)(f) addresses maintaining the confidentiality of personal data, stating that “personal data shall be processed in a manner that ensures appropriate security of personal data, using appropriate technical or organizational measures (‘integrity and confidentiality’).” Article 5(2) creates the need to maintain verifiable evidence of compliance with the confidentiality of personal data processing, stating that “the controller shall be responsible for and be able to demonstrate compliance with paragraph 1 (‘accountability’).”

Article 32, paragraph 1(a), specifies the use of encryption to secure personal data, stating that “controllers and processors shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including, where appropriate, the following: (a) anonymization and encryption of personal data.” Article 32, paragraph 1(d), refers to the regular evaluation of the security of processing, stating that “controllers and processors shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including, where appropriate, the following: (a) anonymization and encryption of personal data.”

There are many concerns to consider when protecting the privacy of transmitted electronic information:

A. Protection against interception – Protects messages in transit over the Internet, regardless of the recipient's server, provider, or settings. This should also protect against common interception tactics that compromise standard TLS server transmissions, such as TLS downgrade attacks, which are most successful when the recipient server reports that it cannot accept TLS transmissions, either constantly or intermittently, and there is no built-in fallback to another encrypted delivery method.

B. Protection from eavesdroppers - Options for protecting messages as they travel from the sender through the sender's organization and as they travel to the recipient's destination. There are various categories of eavesdroppers - these could be inquisitive employees within the sender or recipient's organization, internet criminals, or outsourcing providers with access to email. In the latter example, consider that the recipient uses Gmail and that the sender's messages are encrypted by the recipient's email provider (in this case, Gmail). In this example, the recipient's provider offers a free email service known for relying on marketing user information. The content of the recipient's messages is analyzed by Google, which records the content and sells a profile of the sender and/or recipient based on the content of the emails associated with their email addresses and other collected data to "improve" their service (also known as a marketing profile of the sender and/or recipient).

C. Protection from Social Engineering Leaks - Your data protection plan should also consider how to protect against fraudulent emails received by human resources, financial, or other staff handling sensitive customer information that lure them into responding with attached sensitive data. A common tactic involves an online criminal posing as an employee and sending an email to the HR department requesting payroll or tax information. The response email is then designed so that the employee's response is unknowingly routed to the online criminal. The technology industry calls this a "whaling" attack, a more socially engineered approach to "spear phishing." The Federal Bureau of Investigation refers to this as a business email compromise attack. The best solutions detect this type of social engineering data breach.

D. Automated Rules - Some may prefer the option of using content added to the message before sending, such as keywords in the subject field, or directly instructing the server to encrypt the message based on a match of the message content to a content policy added to the server.

And the social elements of the means of transmitting information privately must also be considered:

A. Ease of Use - If a service is too complex for the sender, they may ultimately choose not to use it. For example, if the sender must engage in the exchange of encryption keys or certificates with the intended recipient, the service's usability is significantly limited. Ease of use is essential in today's enterprise environment.

B. Convenience for recipients that avoids frustration. If a service is cumbersome for recipients, such as requiring numerous steps to set up an account to retrieve messages, recipients may naturally complain or fail to receive important messages. This is especially important when the sender is sending personal information that requires proof of delivery, such as customer account information or investment risk disclosures. In such cases, sending a link that involves a complex process of uploading or retrieving the information to a portal is likely to result in the recipient not receiving the information and may not successfully comply with delivery or notification requirements.

C. Peace of mind - Provides the sender with proof of delivery and proof of encrypted delivery; and provides the recipient with a visible indication that the sender has chosen to treat sensitive information as secure and transmit it to the recipient. For example, simple use of TLS does neither of these things.

D. No Storage - Most companies prefer that messages not be stored elsewhere during transmission, as this creates additional risks of message compromise. The security of intermediate storage servers must be monitored, as this creates potential points of subsequent data access, depending on the data retention and deletion techniques of the intermediate server. For example, when transferring sensitive documents using file-sharing services, users rarely return to delete the documents after transfer. The documents remain accessible for extended periods via the shared link. Furthermore, secure e-delivery systems often store copies of documents on intermediate servers for extended periods until they are retrieved (which may never happen), or even if retrieved, until optimal deletion procedures are in place. This can unnecessarily expose sensitive data.

E. User Inattention - Protection against recipients responding to received sensitive information. Sensitive data is left in the email thread, and replies are transmitted insecurely or without the sender's desired level of security for that type of message or message content.

If you are considering sending messages in a more secure manner and doing so for compliance reasons (e.g., to comply with data privacy rules), you should consider how to maintain a record of encrypted transmissions and how senders can maintain audit-ready data privacy compliance evidence. The General Data Protection Regulation (GDPR), Regulation (EU) 2016/679, imposes fines of up to 4% of global turnover, for example, up to €20 million. Given the potential for fines related to a percentage of global turnover, compliance consultants should educate clients on the importance of maintaining records of "proof of data privacy compliance"; better automated and verifiable evidence at the message level (as described in Articles 5.1 & 2 and 32.1 of the GDPR), as accountability is a key requirement of the GDPR directive. Regulators in the US and other states and countries are likely to follow these guidelines in the future. Industry groups are also likely to develop industry best practices for secure data transmission and certification.

Due to the importance of GDPR fines for data breaches, sender organizations must maintain audit-ready evidence of encrypted delivery on a per-message basis. Simply having a "policy" in place doesn't guarantee that the policy is working properly. For example, a policy might automate transmissions over TLS, but that doesn't mean the message was sent over TLS (consider TLS downgrade attacks). It also doesn't guarantee that the server was operating properly when investigating a dispute or breach months or years later. Audit-ready evidence on a per-message basis is ideal for easily proving compliance in compliance reviews, compliance audits, or when a sender reports a data breach (which could occur after the recipient's system was compromised or the recipient delivered the message).

While many companies rely on TLS forwarding for secure transmission, many companies and email service providers either do not or use what are considered insecure versions of TLS (i.e., TLS 1.0). In a January 14, 2019, blog post, Microsoft announced that as of October 31, 2018, Office 365 will no longer support TLS 1.0 and 1.1 and will “not fix any new issues discovered in clients, devices, or services.” However, it noted that it will continue to deliver to recipients at these levels of TLS. See https://docs.microsoft.com/en-us/office365/securitycompliance/technical-reference-details-about-encryption#TLS11and12deprecation.

Microsoft reported on August 16, 2018, that "Insights point to connectors that help bring to your attention potential TLS encryption issues. Insights indicate that more than 25% of connections are TLS-free or more than 50% are TLS 1.0-free. If you see these insights, you should investigate the email servers associated with the connector or contact your partner organization." https://docs.microsoft.com/en-us/office365/securitycompliance/mfi-outbound-and-inbound-mail-flow (March 6, 2019)

On August 6, 2019, Microsoft discussed the findings of its Outbound and Inbound Mail Flow widget. Applying the widget to an example enterprise, the widget reported that 8,458 outbound and 6,292 inbound messages were secured by TLS 1.2 or later. Microsoft used this data to support the deprecation of TLS 1.0 and 1.1.

The RPost blog by Zafar Khan discussed this on December 7, 2018, in a post titled “Not All TLS is Created Equal” (https://www.rpost.com/news/not-tls-created-equal/), citing statistics from Google Email Transparency Report data (https://transparencyreport.google.com/safer-email/overview?hl=en) that came to similar conclusions as Microsoft Insight.

Google summarizes its explanation of TLS encryption and its problems as follows: "When email is encrypted in transit with a security protocol called Transport Layer Security (TLS), it becomes harder for others to read what you send. A growing number of email providers are working to encrypt email messages in transit. The data here shows the current state of email encryption in transit. Many email providers do not encrypt messages in transit. When you send or receive email through one of these providers, your messages are exposed to snoopers as a postcard in your mail. A growing number of email providers are working to change this by encrypting messages sent to and from their services using Transport Layer Security (TLS). In general, the use of encryption in transit continues to increase over time as more providers enable and maintain support. Factors such as changing email volumes may explain other fluctuations in these encryption statistics." See https://transparencyreport.google.com/safer-email/overview?hl=en (March 6, 2019).

How encryption works:

If you send a letter to a friend, you want her to be the only one who reads it. However, many things can happen to the letter on its way from you to her, and there may be prying eyes trying to read it. That's why important messages are sent sealed in an envelope, not on the back of a postcard. Sending and receiving email works in a similar way. However, if you send or receive messages with an email provider that doesn't transmit messages over a secure connection, your emails may be open to snooping.

Transport Layer Security (TLS)

Encryption using Transport Layer Security (TLS) protects messages from prying eyes while they are in transit. TLS is a protocol that securely encrypts and transmits both inbound and outbound mail traffic. It prevents eavesdropping between mail servers, keeping messages private while traveling between email providers. TLS is becoming the standard for secure email.

Encryption is for everyone.

Your messages are encrypted only if both you and the person you're exchanging email with use an email provider that supports Transport Layer Security. Not all email providers use TLS, and if you send or receive messages from a provider that doesn't, eavesdroppers can read your messages. While TLS isn't a perfect solution, if everyone used it, email snooping would be more difficult and expensive than it is today.

Similar to Microsoft's reporting, Google tracks aggregate statistics on all inbound and outbound message traffic for hosted email services (e.g., Microsoft Office 365, Google Gmail, and Google G-Suite). For example, Google reported that 92% of the inbound and outbound traffic it processed was encrypted between December 6, 2019, and March 6, 2019. Additionally, Microsoft and Google offer the ability to track encryption of inbound and outbound messages on a per-domain basis.

Many software service sales professionals use security phrases to simplify cybersecurity. As technology advances and threats become increasingly sophisticated, encrypting email to comply with privacy regulations is no longer simple. Hackers pay attention to detail.

Here, we'll decipher everything commonly referred to as security, demystify TLS, and explain why the details are important. "Not all TLS is created equal. Not every email you think is sent over TLS is actually secure," explains Steve Anderson, an insurance technology expert and LinkedIn influencer with over 330,000 followers.

First, what is TLS? TLS stands for Transport Layer Security. Simply put, it's a means of encrypting communications between two participating devices. It's primarily used when communicating between web browsers and web servers. It's easy to disable "unsafe" connections, display pop-up warnings, or even block page display in your browser.

However, email presents a more complex problem. When you log in to Gmail via the Chrome browser, the connection from your device to Google's email servers is secured in this way. But what happens to your email after you hit send and it travels from Google's Gmail servers to the recipient? This may or may not involve "opportunistic TLS," which is used by default by many major email providers (Microsoft Hosted Exchange Office 365, Gmail, etc.).

First, let's remember that for most users, the most important part of an email is its delivery to its intended recipient. Traditionally, whether it's visible to that recipient was an afterthought.

Enter opportunistic TLS. Here, Gmail, the sending server, will first attempt secure TLS email delivery (SMTP) if given the opportunity, and if it can't deliver securely the second time, it will fall back to less secure or insecure automatic and invisible delivery.

Sounds pretty good; anyone receiving email would have the same mindset and accept emails sent from Gmail over a secure connection. Right? No.

According to the constantly updated Gmail Transparency Report, 88 to 91% of emails sent to and from Gmail are transmitted using TLS. This means that more than 10% are typically sent and received without security. Therefore, one in ten messages sent or received through Gmail are sent without security. This could be similar to email hosted in Office 365.

One in ten unsecured emails might not seem like a bad thing, but consider that it could be much worse. According to the above report, for many recipient email domains, such as Charter.net in the US, Bigpond in Australia, and Videotron via Bell in Canada, emails sent to and from these domains via Gmail are unencrypted (0%), while for companies like Amazon, 57% are. What about the countless smaller companies? Do they have better security than Amazon? (Data reported in Google's December 2018 Transparency Report).

There's a flaw here. None of these transparency reports distinguishes between the many TLS connections considered insecure. Typically, there are multiple versions of TLS that are considered secure: TLS 1.0, TLS 1.1, TLS 1.2, and now TLS 1.3.

Focusing on TLS 1.0 presents a known risk, particularly TLS downgrade attacks. Simply put, hackers can intercept TLS 1.0 checks before server-to-server communication and trick the sending server into sending messages in an insecure manner. Security experts have been encouraging IT administrators to upgrade from TLS 1.0 for over a decade; however, its use persists, typically accounting for over 15% of all TLS email connections. Therefore, 10% may be sent insecurely (without TLS), and 15% may be sent using a TLS version with known vulnerabilities. At least 25% of emails (one in four) are now affected. The percentage may be even higher for smaller businesses communicating with customers and individuals. The question is: what to do?

In a 2018 blog post, Microsoft stated that it would no longer support TLS 1.0, stating, "This does not mean Office 365 will block TLS 1.0 and 1.1 connections. There is no official date for disabling or removing TLS 1.0 and 1.1 from our TLS services for customer [email] connections." And remember, TLS 1.0 is known to be non-compliant in some circles (e.g., PCI financial compliance standards). What about HIPAA? PII? NPI? GDPR privacy compliance? If TLS 1.0 has known vulnerabilities, it may not be considered a "privacy compliant" transport. Time will tell.

The bottom line is that Microsoft Office 365, G Suite, and other "opportunistic TLS" systems are likely sending at least 25% of emails insecurely or in a less secure manner than is required for privacy compliance. There's no easy fix for these systems, as the option to not deliver emails at all (as Microsoft has pointed out) is out of the question, and this would create confusion for both senders and recipients. From the blog post, they seem to prefer insecure delivery over no delivery at all.

What to do: Opportunistic TLS with automatic fallback

All you need is an add-on to Gmail, Office 365, Zimbra, or any other email service. This simple-to-use service dynamically and automatically reverts to an alternative method of email transmission encryption when TLS is unavailable or an insecure version of TLS is present, without any inconvenience or burden to the sender or recipient.

The importance of third-party verifiable evidence protects the sender organization, especially in cases where a recipient claims a data breach. As shown in Figure 3, the 2017-2018 RPost survey conducted by Khan of RPost service subscribers revealed that the majority of users used email encryption to comply with privacy regulations.

According to survey respondents, one of the most important features is receipt, which provides proof of delivery and privacy compliance, as illustrated by the graph in Figure 4. The RPost system receipt provides proof of delivery. The RPost system receipt also indicates that the message has been selected for transmission with a specific encryption service. The RPost system receipt contains a portion of the server transmission history associated with a specific transmission.

If the sender organization generates significant revenue globally and regulatory authorities offer "whistleblower" rewards based on a percentage of the data breach fine, the sender should have readily verifiable third-party evidence that any breach claims occurred after the message was securely received (or delivered) by the recipient's system. It is desirable to have a message-based record that verifies that the content was encrypted and successfully delivered, providing evidence to mitigate the risk of a data breach. This minimizes the risk of the sender becoming a target.

For purposes of explanation, specific nomenclature is provided to provide a thorough understanding of the present disclosure. Descriptions of specific applications and methods are provided by way of example only. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and steps disclosed herein.

In the following description, numerous specific details are set forth to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure may be practiced without these specific details. In other instances, well-known components or methods have been described in block diagrams or schematics to avoid unnecessarily obscuring the present disclosure. Additional specific numeric reference numbers, such as "first driver," may be created. However, specific numeric reference numbers should not be construed as literal sequential order, but rather as "first driver" being different from "second driver." Accordingly, the specific details described are merely illustrative. The specific details may be modified and still be considered within the spirit and scope of the present disclosure. The term "coupled" is defined to mean directly connected to a component or indirectly connected to a component through another component.

Throughout the description, reference will be made to various software programs and hardware components that provide and perform the features and functions of various embodiments of the present disclosure. The software programs may be embodied in a machine-readable medium. A machine-readable medium includes any mechanism that provides, stores, or transmits information in a form readable by a machine, such as, for example, a computer, a server, or other such device. For example, a machine-readable medium includes read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; digital video disks (DVDs); EPROM; EEPROM; flash memory; magnetic or optical cards; or any type of medium suitable for storing electronic instructions.

Some portions of this detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within computer memory. These algorithmic descriptions and representations are the means used by those skilled in the art of data processing to most effectively communicate their work to others in the art. An algorithm is generally considered herein to be a self-consistent sequence of steps leading to a desired result. The steps involve physical manipulations of physical quantities. Typically, but not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transmitted, combined, compared, and manipulated. It has sometimes proven convenient, primarily for general use, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. These algorithms can be written in a variety of software programming languages. Furthermore, an algorithm can be implemented as lines of software code, as composed logic gates, or as a combination of the two.

However, it should be borne in mind that all such terms and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to those quantities. Unless specifically stated otherwise clearly from the above discussion, it is to be understood that discussions throughout the description using terms such as “processing” or “calculating” or “determining” or “displaying” do not refer to operations and processes of a general-purpose computer system or similar electronic computing device. Rather, in the context of the description below, such terms relate to processes executed by a computer or similar electronic computing device that manipulate and transform data represented as physical (electronic) quantities within the computer system’s registers and memory into other data similarly represented as physical quantities within the computer system’s memory or registers or other such information storage, transmission, or display devices, under the control of embedded or software programming instructions designed to perform the particular functions of the various embodiments of the present invention.

In one embodiment, the logic consists of electronic circuits following the rules of Boolean Logic, software containing patterns of instructions, or any combination of the two.

The term "server" is used throughout the following description. Those skilled in the art will understand that a server is a computer program that runs on the same computer or processor as the server application and/or provides services to other computer programs or processors than the computer or processor on which the server application is running. Although other programs and applications may run on the same computer or processor, the computer or processor on which the server program runs is often referred to as the server. It will be appreciated that the server forms part of a server/client model. Thus, the processor running the server program can either act as a client, requesting services from other programs, or as a server, providing services to other programs upon request. It will be appreciated that the computer or processor on which the server program runs may have access to other resources, such as memory, storage media, input/output devices, and communication modules.

Similarly, a cloud server is a server that provides shared services to various clients accessing the cloud server via networks such as local area networks and the Internet. In a cloud-based system, the server is remote from the clients, and various clients share the cloud server's resources. Information is passed from the clients to the server and returned to the clients via a network, typically the Internet.

FIG. 1 illustrates an exemplary computer system (10) that may be used with some embodiments of the present invention, which may be, for example, a server or client computer system. The computer system (10) may take any suitable form, including, but not limited to, an embedded computer system, a system on a chip (SOC), a single board computer system (SBC) (e.g., a computer on module (COM) or a system on module (SOM)), a laptop or notebook computer system, a smart phone, a personal digital assistant (PDA), a server, a tablet computer system, a kiosk, a terminal, a mainframe, a mesh of computer systems, and the like. The computer system (10) may be a combination of various forms. The computer system (500) may include one or more computer systems, may be single or distributed, may span multiple locations, may span multiple systems, or may reside in the cloud (which may include one or more cloud components in one or more networks).

In one embodiment, a computer system (10) may include one or more processors (11), memory (12), storage (13), an input/output (I/O) interface (14), a communication interface (15), and a bus (16). While this disclosure describes and exemplifies a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates other forms of computer systems having any suitable number of components in any suitable arrangement.

In one embodiment, the processor (11) includes hardware for executing instructions, such as those constituting software. Here, reference to software may include one or more applications, byte codes, one or more computer programs, one or more executable modules or APIs, one or more instructions, logic, machine code, one or more scripts, or source code. For example, and without limitation, to execute an instruction, the processor (11) retrieves the instruction from an internal register, an internal cache, memory (12), or storage (13); decodes and executes the instruction; and then writes one or more results to the internal register, internal cache, memory (12), or storage (13). In one embodiment, the processor (11) may include one or more internal caches for addressing instructions or data. The memory (13) may be random access memory (RAM), static RAM, dynamic RAM, or any other suitable memory. The storage (15) may be a hard drive, a floppy disk drive, flash memory, an optical disk, a magnetic tape, or any other form of storage device capable of storing data (including instructions for execution by the processor).

In one embodiment, storage (13) may be mass storage for data or instructions, including but not limited to, an HDD, a solid state drive, a disk drive, flash memory, an optical disk (such as a DVD, CD, Blu-ray, etc.), a magneto-optical disk, a magnetic tape, or any other hardware device that stores computer-readable media, data, and/or a combination thereof. Storage (13) may be internal or external to the computer system (10).

In one embodiment, an input/output (I/O) interface (304) includes hardware, software, or both for providing one or more interfaces for communication between a computer system (10) and one or more I/O devices. The computer system (10) may have one or more of these I/O devices, as appropriate. By way of example and without limitation, the I/O devices may include one or more mice, keyboards, keypads, cameras, microphones, monitors, displays, printers, scanners, speakers, cameras, touch screens, trackballs, trackpads, biometric input devices or sensors, and the like.

In another embodiment, the communication interface (15) comprises hardware, software, or both that provides one or more interfaces for communication between one or more computer systems or one or more networks. The communication interface (15) may include a network interface controller (NIC) or a network adapter for communicating with an Ethernet or other wired-based network, or a wireless NIC or a wireless adapter for communicating with a wireless network, such as a Wi-Fi network. In one example, the bus (16) comprises any hardware, software, or both that couples the components of the computer system (1) to each other.

Figure 2 is a graphical representation of an exemplary network (100) that may be used to facilitate various embodiments of the present invention. The server (105) is operated by a service organization and generally includes at least one processor, input and output devices or devices, memory, storage, and a communication interface, as discussed above with respect to Figure 1. The server also operates under the control of specialized software programming commands designed to perform the various processes described above. While the exemplary network (100) is described in terms of a server operated by a service organization, it should be understood that the server may be operated by a third party employed by the service organization or under the control of the service organization. The server may also be operated by a third party independent of the service organization that provides information and/or data to the service organization so that the service organization can provide services to the service organization's clients.

A data storage device (110), which may be, but is not necessarily, separate from the service, may be accessed by the server (105) and may be used to store information related to dates and any other data related to the operation of various embodiments of the systems and methods described above. The data storage device (110) may be directly connected to the server or may be accessed by the server via a network or the Internet (115). The data storage device may also be a virtual storage device or memory located in the cloud. Additionally, one or more providers (120) or clients (125) are connected via a network or the Internet (115).

From the above, it may be apparent that the various embodiments disclosed herein may be implemented by computers, servers, or other processors that appear to be organized into a conventional distributed processing system architecture. However, the various embodiments described herein are not conventional, as they bridge multiple remote information sources, such as legacy computer applications, legacy storage media, and data residing on media and workstation storage, and involve sophisticated analysis of various portions of email messages, and the methods, protocols, and communication paths used to transmit and receive email messages. In fact, when the various embodiments of the present disclosure are operated using computers, servers, and processors, these embodiments transform such computers, servers, and processors into computers, servers, and processors that are specifically programmed in a manner that not only improves the operation of the various hardware and software components, but also significantly enhances the transmission, reception, and processing of email messages.

For the purposes of the present invention, techniques known to those skilled in the art and methods for implementing the present invention will utilize technical components commonly used by those skilled in the art. Therefore, this description of the present invention does not describe these component technologies. This includes the use of:

1. Sender's mail client

2. Sender's mail server

3. Sender Mail Gateway

4. Filtering email content

5. Secure Message Service Server

6. Secure Transport Protocol

7. Email encryption methods and protocols

8. Database Logging and Connection

9. RPost registration email service technology (patented)

10. RPost registration reception authentication service technology (patent)

11. Hashing, Digital Signatures, and Blockchain Technology

12. RPost Sidenote Service Technology (Patent)

13. Recipient Mail Gateway

14. Recipient mail server

15. Recipient email client such as Microsoft Outlook or Gmail

16. Part of the message

a. Message header

b. Message content

17. Message transfer protocol including secure message transfer protocol

18. Data reporting provided by email

19. Web view of data reporting

20. Encryption and Authentication Processes and Protocols

21. Responding to received electronic messages

22. Extract content and create images of the content using software tools.

23. Use the tool to generate content that can be associated with HTML links and self-extract HTML links inserted in emails.

24. Linking information in a database

25. Software Operation of Web and Email Servers

The term “email” as used herein may refer to any type of electronic message; the term “email protocol” may refer to any electronic data interchange protocol; and the term “electronic file” may refer to any type of file.

The various embodiments described herein may be implemented in their entirety or in selected portions only. For the purposes of this disclosure, implementations of each portion in one embodiment are considered, with other portions discernible to a skilled practitioner within the scope of the present invention.

A. Registered Encryption

Registered Encryption is a trademark of RPOST Communications Limited. Encrypted Message Delivery Tracking and Proof: Delivers encrypted messages to the intended recipient with visibility and auditable evidence of secure delivery. This is based on the invention described in Tomkow's U.S. Patent No. 7,966,372, which is incorporated herein in its entirety.

Secure inbound transmission records of messages from sender to RPost

1. Use the analysis of message headers received from the receiving system.

An embodiment of the disclosed system includes reviewing the header of a received message. In this embodiment, "RPost" refers to an intermediate server that directs a message along its way from a sender to a receiver, and an intermediate server that relays the receiver's message to the receiver.

In this embodiment, the RPost system records whether a message arrived at one of the RPost servers via TLS by recording information in the header of the received message. Since this header is present in a copy of the received message, the receiving system, in effect, already has information about whether the last transmission to the receiving server was performed via TLS if the receiving server or a knowledgeable individual examines each header of the recipient. In this embodiment, the RPost intermediary server system extracts data indicating that the message was received via TLS from the message header of the message received from the sender at the RPost intermediary server, and stores a portion of this message header in a database for later use in addition to a receipt record or report.

If a message arriving at an RPost server travels through multiple servers before reaching the RPost server, it may have passed through a non-TLS server along the way, even if the final hop (or server) to the RPost was TLS. While a full record of whether each hop was TLS could be part of the message header when the message is received by the RPost intermediary, without the present invention, there is no standard way to record that the connection from the sender to the intermediary was a secure TLS connection.

In one embodiment, since information about a received message may be recorded in different formats depending on the sending or relaying MTA server, a complete list of all known MTA servers may be built, and if the system cannot detect TLS due to the placement of headers in an unknown format, the system does not record a TLS secure connection to that server. The system includes a process for placing messages with unknown header formats into an investigation queue for review and learning or for machine learning analysis of new message header types, and then dynamically building and updating the list by adding secure connection protocol elements of that type to the list of known ones.

Often, messages will not actually be transmitted over TLS when they are transferred from an internal mail server to a border gateway server, as TLS is slower than without it. While this isn't necessarily insecure, some method of indicating that a particular transmission is internal is needed to determine whether it is occurring. This is usually detectable, but not always easy or foolproof. Information about the last known server and the transmission protocols from various servers, identified from the server sequence and headers, can be analyzed with rules that are dynamically updated based on learning.

In one embodiment, the system will record the last hop from the sender's gateway to the RPost intermediate server, at least via TLS (or another secure protocol). This may involve recording the name and IP address of the sending gateway server of the last hop in the RPost. If an encryption option is indicated in the received message, the system may record whether the message was received encrypted (and, for example, by which method, TLS, TLS version, or PKI). While all the audit information necessary to determine whether a message was received by the RPost via TLS is available for human analysis, performing meaningful automated real-time analysis can be very challenging and may require specialized and non-traditional systems. Furthermore, determining whether a message was received securely via another method (e.g., PKI) but delivered without TLS will be part of the analysis.

Examples:

The bold text is elements of the email header of an inbound message received from a sender on the RPost intermediate server that are parsed and copied into RPost's database.

Received: from abc.luxsci.com ([1.1.1.1])

by def.luxsci.com (8.14.4/8.13.8) with ESMTP id r7JEfLgH003867

( version=TLSv1 /SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)

for <user-xyz@def.luxsci.com>; Mon, 19 Aug 2013 10:41 :21 -0400

Received: from abc.luxsci.com (localhost.localdomain [127.0.0.1])

by abc.luxsci.com (8.14.4/8.13.8) with ESMTP id r7JEfK0Z030182

for <user-xyz@def.luxsci.com>; Mon, 19 Aug 2013 09:41 :20 -0500

Received: (from mail@localhost)

by abc.luxsci.com (8.14.4/8.13.8/Submit) id r7JEfKXD030178

for user-xyz@def.luxsci.com; Mon, 19 Aug 2013 09:41 :20 -0500

Email received inbound from a sender on an RPost server will have a series of headers in the order of the last hop: from the sender to the exchange server, to the gateway server, to the perimeter server service, and finally to the RPost intermediate server—each of which may or may not have a TLS transport level and may have different TLS security protocol levels (i.e., TLS 1.0, 1.1, 1.2, 1.3). The RPost server logs this header and parses it for at least "Last Received From Server Name/Secure by TSL (protocol level)", with the option to run a program to view previous hops. If the received message level is encrypted (i.e., PKI encrypted from the sender to the RPost server), the analysis is ignored (overridden). The sending organization can choose a view level (Last Hop, All Hops) to determine the security for all hops, or only the last hop.

Parsing the email headers of messages received inbound from the sender on the RPost server can be processor intensive, so this parsing can be performed after the message has moved from the processor to the recipient.

The content parsed/copied from the header is placed into a database and categorized based on a hierarchy of what is important to the sender's security (i.e. best, acceptable, fail).

The message is delivered to the recipient according to the sender's secure transmission preferences.

When a message is processed for message level security, the fact that the message was re-encrypted on the RPost server is recorded along with the message ID, re-encryption method, timestamp, etc.

If the message is processed for secure transport (i.e., TLS), then after transmission, in the case of SMTP/ESMTP or other protocols (i.e., HTTP), the message transport protocol information is recorded and parsed to detail the secure transport protocol (i.e., TLS 1.2) successfully used for the transmission and to determine the fact of secure transmission to the recipient in the RPost. Parsing of this protocol information occurs after the message in this embodiment is transmitted to the recipient, due to the additional processing required to parse other transport data and headers after transmission.

This protocol information is stored in a database associated with the message ID and the received secure transmission information.

The parsed/copied message sending protocol portions placed in the database are classified according to their importance to sender security (i.e., Best, Acceptable, Fail). For example, "Best" could mean TLS 1.2 or message-level encryption (i.e., PKI). "Acceptable" could be configured by the sender organization, meaning, for example, TLS 1.1. "Fail" could be configured by the sender organization, meaning, for example, TLS 1.0 or no TLS.

The classifications (received from the sender) and (sent to the receiver) are matched to a chart for display by the sender and/or the sending organization, along with the results (interpretation) and protocol/method data, and the sum of the security levels may be set to the higher of the sum of the levels (received from the sender) and (sent to the receiver).

Example 1. If:

(received from sender) = Best

(sent to recipient) = Acceptable

Result = Acceptable

Example 2. If:

(received from sender) = Best

(sent to recipient) = Fail

Result = Fail

Example 3. If:

(received from sender) = Acceptable

(sent to recipient) = Acceptable

Result = Acceptable

Considering the above example of database records for emails sent from Bob@comopany.com to Sue@network.com and Jin@home.com, this can be summarized as follows, with additional fields for the message ID, the hash of the sent message, additional sender hops extracted from the header, and the level of secure transport at each recorded additional hop. For example, in the case of the Bob to Jim example, the receipt of the message on the RPost server via the RPost server public key PKI applied by the RPost sender app is detected, so the system knows that the message was securely transmitted from the sender Bob mail client (vs. sender domain or server IP address) to Jim on its way to RPost, and records the fact that the RPost server processed the PKI message transmission to decrypt it via the PKI on the RPost server.

From sender to RPOST

When the message itself is received over HTTP (via REST, SOAP, or another API protocol), the receiving RPost message gateway server identifies the message received over HTTP and the HTTP protocol version used. The RPost message gateway server records in its database the logical association with the message it accepted and the server information, which HTTP level transport was used.

If the message itself is received via the HTTP protocol (via a web server or another web transport or messaging protocol), the receiving RPost message gateway server identifies the message received via the HTTP protocol and the HTTP protocol version used. The RPost message gateway server records in its database the logical association with the message it accepted and the server information, which HTTP level transport was used.

For all of the above, including a message ID, a reception timestamp from the RPost server, at least part of a message transfer protocol dialog indicating secure transport, or part of server configuration metadata that verifies that the server only accepts inbound messages received using a particular secure transport protocol or the fact that the RPost server decrypts PKI-encrypted messages received from the RPost server (“secure transport forensics”); and records them in a database that is logically associated and hashed together and/or hashed separately.

Secure transmission forensics are logged and optionally recorded in a database along with a hash of the received message contents.

2. Record the secure outbound transmission of messages from RPost to the recipient.

When a message is received by the RPost server, a decision needs to be made as to how the message is delivered to the intended recipient in a secure manner.

Based on:

A. The sender's characteristics request (the sender or sender settings that determine how the message should be securely transmitted to the recipient (using a secure transmission method, system, or protocol)), the message is transmitted, or

B. Availability of a recipient that accepts a particular type of secure transmission, the message must be transmitted securely to the recipient (using a secure transmission method, system, or protocol), and the message must be transmitted securely to the recipient using one of the selected secure transmission protocols.

In one embodiment, for example, in case (A), the RPost server transmits the message with message-level encryption based on characteristics set by the sender or sender administrator, and the message is encapsulated and transmitted within a 256-bit encrypted PDF file.

For other messages, in case (B), the RPost server transmits the message with message-level encryption based on the characteristics set by the sender or the sender's administrator, with a requirement for TLS 1.2 transport unless it is unavailable, in which case it is encapsulated within a 256-bit encrypted PDF file that is transmitted. For other messages, in case (B), the RPost server transmits the message with message-level encryption based on the characteristics set by the sender or the sender's administrator, with a security requirement of TLS 1.0 or higher, but if the recipient can accept TLS 1.2, the TLS 1.2 protocol is used for secure transport.

The available TLS transport levels can be maintained in a cache, database, or on a server associated with the RPost MTA, and only if that protocol is unavailable will it be retested to determine which protocol is available, reverting to a fallback message-level encryption transport (i.e., AES 256-bit PDF encryption) if the desired protocol is unavailable. The fact, type, and/or level of encryption from RPost to recipient is recorded in the Rpost database.

FIG. 5 illustrates one embodiment (200) of determining which level of secure transport protocol can be received by a particular recipient, which then determines which type or level of encryption to use to transmit the message to the recipient of the message. In this embodiment, the message is received by a server in a registered central server (RCS) (220), such as server Trans X (205), Trans Y (210), or Trans Z (215). This example assumes that Trans X (205) has received the message. The RCS server Trans X calls the “get API” on the MTA (Message Transfer Agent) server MTAXX in step 1. In step 2, the API makes a system call to analyze the type of protocol present in the message. If the message is encrypted with a particular TLS protocol, the API checks in memory, such as the TLS local cache (230), to determine if the system knows the recipient in step 3. If the recipient is known to the server, the API communicates with the RCS server Trans X (205) and instructs the server to use the appropriate TLS or MLE protocol to transmit the message to the recipient, and Trans X then transmits the message to the recipient.

If the recipient is not aware of the system, the API performs an MXLookup to find the domain based on the address contained in the message received in step 4. Once the domain is determined, a copy of the recipient's information is stored in the TLS local cache (230), a command to use the appropriate protocol to transmit the message is communicated to the server Trans X (205), and the message is transmitted to the recipient using the appropriate encryption protocol.

However, in some cases, the recipient may not be able to receive the message using the TLS protocol. In this case, the message will not be delivered until a suitable protocol is determined. In such cases, the message is transmitted using PDF encryption, for example.

When configuring a customer to use a public system, the customer sending the electronic message to the recipient can set the minimum supported TLS protocol for message delivery. In this example, even if the public system supports the recipient's encryption protocol, the customer's settings may override the recipient's server settings. In this case, if the message cannot be received using the recipient's encryption protocol, it may be transmitted to the recipient using, for example, the PDF encryption protocol.

The RPost server records the delivery method used for the actual transmission to each intended recipient. This differs from indicating that an encrypted transmission request was made. The difference here is that each intended recipient has a secure transmission record, along with security forensic metadata.

Considering the above example of a database record for an email sent from Bob@comopany.com to Sue@network.com and Jin@home.com, this can be summarized as follows, with additional fields for the message ID, the hash of the sent message, additional sender hops extracted from the header, and the level of secure transport at each recorded additional hop. For example, in the case of the Bob to Jim example, the message was detected to be received by the RPost server via the RPost server public key PKI applied by the RPost sender app, so the system knows that the message was securely transported from the sender Bob mail client (vs. sender domain or server IP address) to RPost on its way to Jim.

From RPOST to recipient

These records can be combined in a database via a common message ID, contain a hash of the entire forensic metadata logically associated with a hash of the content, and can be generated as a digitally signed “security certificate” in a manner that can prove the original transmission, the content received, the transmission timestamp, sending, delivery, and in the case of PKI, decryption and opening using various methods disclosed in the Tomkow family patents and prior art.

From sender to RPOST

From RPOST to recipient

Reports can include the above summary using formulas or by generating security scores. For example:

If the sender is RPost = Security via PKI, 4 points

If the sender is RPost = Secure TLS 1.2, 3 points

If the sender is RPost = Secure TLS 1.1, 2 points

If the sender is RPost = Secure TLS 1.0, 1 point

If you are the recipient of RPost = Secured via PDF AES-256, 4 points

If you are the recipient of RPost = Secure via TLS 1.2, 3 points

If you are the recipient of RPost = Secure via TLS 1.1, 2 points

If you are the recipient of RPost = Secure via TLS 1.0, 1 point

Generates a flag to alert the sender manager if there is a zero point from the sender to RPost or from RPost to the receiver.

The above scores can be adjusted based on the level of security that is important to the sender organization in the management interface, which additionally allows sender administrators to choose to exclude secure transmission points for specific transport protocols.

A “confidentiality certificate” or “security certificate” or “security certification” record may include delivery status information, may be combined with a database record of specific processing performed as part of the message transfer protocol (i.e., converting the message to a PDF AED-256 wrapper), and may provide a conspicuous indication to the sender and the sending organization that the transmission is certified secure, in accordance with standards established by the sending organization, and may optionally display a security score. This security certificate may be compiled to verify multiple communication threads, including, for example, submissions from a sending application (via SMTP, HTTP, or another protocol) to a processing hub, to a recipient, and then back to the sender and a blind copied recipient (e.g., a digital signature, reply, or response from the recipient) without any evidence of copying or sending. In this example, information regarding the fact of the reply, reply, and digital signature records, or the fact that a message portion has been modified from the sender or response (as further described herein), is recorded in a similar manner.

Messages can be delivered to the intended recipient via HTTP or HTTPS, depending on sender management rules (e.g., link retrieval, large file transfer), and it is understood that HTTPS is permitted and HTTP is not. This information is captured similarly. Additionally, metadata captures whether the message was delivered via HTTPS and the required recipient password, or simply via HTTPS.

In another embodiment of the security certificate, the system will analyze the message and may include the following steps:

1. The RPost system decrypts the received encrypted message sent from the sender's Outlook (i.e. PKI decryption, a way for the RPost code to verify/record that the RPost app actually received the encrypted PKI).

2. The RPost system records the receipt of an inbound message from the sender SMTP via TLS (the key point is how the RPost code confirms/records the fact of receipt in the RPost system via TLS transmission from the sender).

3. The RPost system logs the receipt of inbound messages from API connections (via HTTPS) (the key point is how the RPost code verifies/logs the fact that they were received via secure web service HTTPS transmission from the sender) [in both scenarios, when receiving a secure response or sending a secure bulk email]

4. The RPost system records the delivery of the outbound message to the recipient gateway via TLS (the key point is how the RPost code confirms/records the fact of successful TLS transmission to the recipient gateway).

5. The RPost system records the password and 256-bit encryption that protects PDF messages before sending them to the recipient.

The above content is recorded in RPost's database.

A record is recorded in the RPost database along with an added record inside the registered recipient in the text file displayed upon authentication and the fact that 1+4, 2+4, 3+4 or 1+5, 2+5 or 3+5 is performed to provide confirmation of the encrypted transmission in the recipient.

Tracking and Proof of Receipt of Encrypted Inbound Messages: Receive inbound messages with auditable and transparent proof of secure delivery from the original sender. Recipients can also view a record reporting secure delivery from the sender, along with a record confirming message receipt (via RPost).

A secure gateway server may use the same elements mentioned to log inbound message traffic, analyzing message headers to extract TLS or message-level encryption data, and may place marks in message headers, subject lines, or bodies to authenticate secure receipt.

B. REDACTED REPLY ^TM

Modified Response is a trademark of Rpost Communication Limited.

Registered Modification of Response Message Part : Modify the message part from the email thread of the sender's message content when the recipient responds using the sender's option to register the fact of modification to the sender.

Modifying part of the response can be done in one of the following ways:

1. Specify a highly confidential message section

The sender's mail client's user interface text box may be a place where the sender can add certain highly sensitive text, such as credit card numbers or medical record information.

Alternatively, the sender can embed highly sensitive information inside a specific type of bracket structure, such as ^Very sensitive content here^.

2. Securely transmit to recipient

The problem arises when a secure message is sent to a recipient over TLS, confident that the sender has taken steps to ensure its secure transmission. However, surprisingly, the recipient may respond with a casual "Thank you!", while their highly sensitive information is returned to them unsecured (through all hops and servers), exposing the sender's highly sensitive information.

The message is securely transmitted from the sender to the RPost server (PKI, TLS, etc.), where the server removes the specified highly confidential content, and also

A. Create a small image of the content and a corresponding black image of the same size.

B. An alternative text (Alt-Text) tag is added to the image file, either named by the sender or associated with the sender, or defaults to "Sender's Email Address Click for Sensitive Content." This text should not be easily spoofed by spammers.

C. Place an image in a designated area of the message body via a link configured to automatically extract it from the recipient.

D. The sender can select the number of views of sensitive content and/or the time available after the first view. This is stored on the server.

E. After the image with sensitive content is displayed to its limit by placing a black image in the location associated with the image with sensitive content (as mentioned in D), the image link is redirected to a link to the corresponding black image.

3. From the recipient

When a recipient opens an email sent securely via TLS, they see an alternative text tag if the link doesn't automatically display sensitive content. If not, clicking the link or clicking an image will reveal the sensitive content.

4. When replying

The recipient sees the content, but when responding, the content is not displayed after the response (the link has a timeout after the first view or a specific time after the first view and/or after transmission).

When sensitive content times out, the content space is replaced with a black box called “Modified Content” (as mentioned in E above).

Additional options

It is expected that some senders will not want to send emails containing hyperlinks to certain recipients due to recipient security policies that prevent them from viewing hyperlinks.

The sender or sender administrator can configure the secure content image from the saved image to be replaced with extracted content placed in the text box attached to the email, with the removed content replaced with black text that reads "^Modified content attached to text file^." The attached file can be a text file, HTML file, PDF, encrypted PDF, etc., in alternative embodiments or through the sender settings options.

If the recipient responds, the test file does not follow the response, thus achieving the goal of preventing inadvertent disclosure of highly sensitive information received during or after the response.

Security Certificate

The points added to the security certificate scoring use this modified response system. Additionally, there may be indications of how many times a security image is displayed, such as "Display at once" = "Most secure," "Expires 10 minutes after first display" = "Most secure," or some settings that accidentally prevent a second display.

This feature is intended to prevent the recipient from accidentally revealing the sender's sensitive information when responding. Additional known methods may be implemented to further control or limit the display of sensitive information, but this embodiment is not intended to prevent the recipient from forwarding, copying, or taking screenshots of the content.

Security Certificate Authentication

If necessary to authenticate a security certificate, the message can be re-hashed and compared to the hash on the blockchain, so that the private message does not need to be stored by a third party or returned to the recipient, and either or both the hash of the certificate and the hash of the message can be published on the blockchain.

Alternatively, the registered receiving system disclosed in the Tomkow patent family may include a system processing forensics and/or receiving and/or transmitting by TLS and TLS level number, with other elements including forensic security metadata, security certificates, and the underlying message transfer protocol, and verifying message level encryption (conversion to a 256-bit AES PDF file).

Examples of using blockchain as part of verification include:

There may be some value in storing a hash of the security certificate (“receipt”) data on the blockchain.

The reception may be a JSON object containing all delivery status information and message metadata, along with a base64-encoded string representing the message and associated DSN, MUA, transport protocol, server system data regarding encryption and decryption, etc. The hash for the blockchain may be a normalized representation of the serialized JSON object.

JSON objects can be formatted into HTML via a template engine to generate email receipts or accessed from customer systems on a real-time push basis via webhooks.

The hash posted to the blockchain is digitally signed with the documented RPost address. There is no need to encrypt received data, as any tampering invalidates the receipt.

Simple tools that hash normalized JSON objects and retrieve transaction hashes from the blockchain for verification can be easily created in various languages (Node, Ruby, Python, etc.) and published to public GitHub repositories and package managers (npm, gem, pip, etc.). Docker containers can also be published to Docker Hub.

In this way, enterprise users (IT departments) can install and run their own verifiers with a few commands. These verifiers can then be easily integrated into business processes. RPost still runs the verifiers additionally.

Using the blockchain as a verifier means that RPost does not require key escrows and/or third-party endorsements to continuously support receipt confirmation, as all information confirming receipt is public and the blockchain is distributed and immutable.

Transaction costs are approximately $0.02 per hash (not significant) for writing to the blockchain. Reading transactions incurs no fees. Once implemented, RPost will implement a public blockchain only for non-paying customers and paid users who choose to pay a specific blockchain fee, while a private blockchain is available for testing.

Blockchain solutions may have some advantages in sales and marketing, as their core value proposition is the permanent validity and independent verification of receipts.

Figure 6 lists the various settings available to the sender of a message using the modified response system. In option 1, the system attaches the selected modified response content to the outbound message sent to the recipient as a text file. Options include selecting a file format, such as an HTML file, and, if desired, encrypting the attachment separately.

In Option 2, the system inserts a link to the modified response text within the email body. In one embodiment, the browser option is to open a new browser window when the modified response text link is clicked, or to activate the link with the modified response text displayed when the link is activated. Multiple options for this step are also provided, which are exemplary and non-limiting. For example, if the sender chooses to have the link open a browser window containing the modified response text when clicked, the sender can also configure various settings to control what happens when the link is clicked. For example, the sender can configure the link to be locked, preventing the modified response text from being copied. Alternatively, the sender can configure the link to allow the text to be copied. In another embodiment, the sender can add a customer logo to the browser when the browser is opened. The number of times the recipient can view the modified response text can also be configured by the sender using an input field or drop-down list.

In another embodiment, the sender can configure the link to limit the time the modified response text is visible. The sender can also provide text that appears in the browser window when the link is clicked. For example, the browser window could display a message such as, "The following information is confidential. If you are not the intended recipient of this confidential and privileged information, please delete it immediately. Do not distribute this information."

In another option, the modified content is removed and displayed as an image within the email. The image file is stored in a temporary storage area associated with the web link, and the link is also stored. In one embodiment, the system may create a second image file of the same size, black, with white text labeled "Modified Content." The system may then add replacement text to the image file, stating "Modified: Click to view." In one embodiment, viewing of the image file is permitted only when the viewer uses the original IP address of the first view, only for a certain number of displays, and/or only for a certain period of time, as configured by the sender.

In one embodiment, the system displays an image containing modified content by implementing software instructions that remove the content and convert an image within the email, e.g., text marked for modification, into an image file; stores the image file in a secure temporary storage area associated with the web link and creates a link to the image file. The sender may also create a second image file of the same size (height, width) that is black with white text “Modified Content”; adds alternative text to the image file, e.g., “Modified: Click to View”; records the IP address of the first viewer; and configures the system to allow viewing of the image file (i) only from the original IP address, and/or (ii) only on a certain number of displays, and/or (iii) only during a certain time period, where (i), (ii) and (iii) are configurable by the sender company.

Figure 7 illustrates a workflow for a modified response embodiment. The sender in box (1) creates an outbound email (box (2)) that is sent to the RPost server in box (3). After processing in the RPost network, the outbound email is transmitted from the RPost in box (4) to the recipient in box (5). In this embodiment, the RPost network may be a sender, a sender email server, a sender gateway, or an intermediate server, as identified in box (3) and illustrated in Figure 7.

Figure 8 illustrates two options available to the sender when preparing an email message using the modified response feature. In this exemplary embodiment, in the first option, the sender inserts the modified response text within the caret symbol (movement (6)). Alternatively, various symbols can be used. Furthermore, the modified response text can consist of multiple lines, spaces, and line breaks.

Figure 9 illustrates a second option available to the sender when preparing an email message using the modified response feature. This option allows the user to insert modified response text within the modified response feature of the sender app used for the RPost service. In one embodiment, as illustrated in Figure 9, the user activates a menu from the RPost application (250), activates the modified response input box (255), and inserts the text to be modified into the box indicated by box (260).

Figure 10 illustrates the outbound path of an email from the sender (or sender server) to the RPost network for processing. The email is securely transmitted to the RPost network along with the modified response text. The text is either included in the email body, enclosed in two up-carrot symbols, or in an encrypted data file sent by the RPost application.

As illustrated in Figure 11, the RPost network service extracts the modified response text from two up-caret symbols or a data file sent from the RPost application and processes the email according to customer or user settings. The sender can configure the RPost system to send the modified response text as a text file attached to an outbound file or to add a link to the message associated with the modified response text. The system can be used to configure the link with the following options: 1) lock the modified response text so that it cannot be copied (yes/no); 2) allow copying of the modified response text (yes/no); 3) add the customer logo to the browser window (navigation); 4) allow the number of times the modified response text can be viewed using a drop-down menu; 5) allow the number of times the modified response text can be viewed per view using a drop-down menu; and 6) display selected text in the browser window, for example, “The following information is confidential. If you are not the intended recipient of confidential and privileged information contained in this email, please delete it immediately. Do not disseminate this information.”

Figure 12 illustrates an exemplary outbound email path from the RPost network to a recipient. The RPost network sends an email to the recipient based on customer or user settings. In one optional embodiment, the system attaches the modified response content to the outbound message as a text file, as illustrated in box (280). The text file may be in various formats, such as HTML, PDF, encrypted PDF, TIFF, JPG, etc. The file may be encrypted using various methods, or the file may be unencrypted. As illustrated in Figure 12, the recipient receives an electronic message (email) containing the modified response text attachment, as illustrated in box (280), including a message in the email (box (285)) indicating that the attachment includes the modified text. Clicking on the attachment opens a window containing the modified response text, as illustrated in box (290).

In a second exemplary embodiment, the system inserts a link to the modified response text within the body of the email, as illustrated in FIG. 13. In this option, the user can click the link to open a browser window to view the modified response text. The RPost network system adds the link to the outgoing email sent to the recipient. When the email is opened by the recipient in box (300), a message (305) containing text informing the recipient that the modified response text can be viewed by clicking the link is provided to the recipient. Clicking the link causes the modified response text to be displayed to the recipient, as illustrated in box (310).

Figure 14 illustrates various browser window settings that a sender can configure to configure the behavior of a link (Figure 13) when a recipient activates the link. For example, a link can be configured with the following options: 1) Lock modified response text so that it cannot be copied (yes/no); 2) Allow modified response text to be copied (yes/no); 3) Add a customer logo to the browser window (navigation); 4) View the number of times modified response text can be viewed, which can be set using a drop-down menu; 5) View the amount of time modified response text can be viewed per view, which can be set using a drop-down menu; and 6) Display selected text in the browser window (box (320)), for example, “The following information is confidential. If you are not the intended recipient of confidential and privileged information contained in this email, please delete it immediately. Do not disseminate this information.”

Figure 15 illustrates another embodiment of a modified response text window according to user settings. In this embodiment, the recipient receives an email containing the modified response text contained in an email or browser window, as illustrated in box (300).

Figure 16 illustrates an exemplary embodiment of the process that occurs when a recipient replies back to the sender. In this case, the modified text is not attached to the response, as shown in boxes (340, 350), or is still modified and therefore not visible in the response message. The link for viewing the modified text can be configured with IP and/or instant call restrictions, as described above, so that when the link is later clicked, the browser window will display the text, for example, "The modified text has expired. Please contact the sender for more information."

Figure 17 illustrates an exemplary configuration menu of one embodiment of the present invention that can be used to configure the system to meet the needs of the sender or the sender's organization. For example, the redaction option can be configured to pre-select an encryption option to encrypt the redacted text. As shown in Figure 18, the original text to be redacted can be extracted from the sender's system, encrypted, and transmitted as an attachment, or alternatively, transmitted in the message header and transmitted over the RPost network.

Figure 19 illustrates another embodiment where a modification option may be selected to pre-select text based on content markers for processing messages at an outbound email gateway server using DLP or filtering rules.

Figure 20 is a flowchart illustrating one embodiment of a system including a modified response system (400). This system is used by senders who are authorized and registered to use the services provided by the RPost server. The message content is marked for modification by the sender in box (405). In box (410), the message is identified for modification processing by the server or software, which may be located on the server or the user's client system. One option that may be selected, as illustrated in box (415), is that the message may be transmitted to the RPost server via secure transmission.

In box (420), the message is routed to the modification server. The message received at the RPost server is processed by a process running on the RPost server, which then queries box (430) to determine the modification settings set by the sender. In box (435), the modified content is removed from the message according to the settings determined in box (430). In one embodiment, the modified content is temporarily stored in the memory of box (440). In another embodiment, the storage of the modified content may be configured to restrict the viewing rights of recipients or users who wish to view the modified content in box (445).

In another embodiment, the modified message is reformatted in box (450) according to the format settings determined by the system in box (430). The modified message is transmitted to the recipient in box (455), which may be accomplished via a secure transmission route, as shown in box (460). The recipient opens the modified message in box (465) and views the modified content according to the sender settings in box (470). As illustrated in FIG. 19, the recipient can alternatively view the modified content in box (470) by clicking on a link stored in the message, which activates the system to provide the recipient with the modified content temporarily stored in memory.

In another embodiment, the process may branch directly from box (440) to box (470), and the recipient may see the modified content according to the sender's settings. In another embodiment, as described above, the recipient may respond to the message in box (475), and the response message may be structured and formatted in box (480) of FIG. 20, without including the modified content, according to the settings set above.

Figure 21 illustrates an exemplary embodiment of a workflow (400) used to perform the disclosed registered encryption embodiment described above. In the exemplary embodiment, a sender (505) transmits an outbound email (510) to a server (515) providing a registered encryption service. After processing, the outbound email (520) is transmitted to a recipient (525). Before, simultaneously with, or after transmitting the processed email to the recipient, the system may forward a registered encrypted record email to the sender at 530 and also transmit a registered encrypted record of a report intended for the sender's organization (535).

When a sender (505) sends a message (510) and the email is to be transmitted securely or encrypted to the recipient, the server on the sender's side (or the sender's) side is intended to transmit the message in an encrypted form, which may be a secure transmission using HTTPS, TLS, or another protocol, or a message secured at the message level using PKI, PGP, or another encryption system. The RPost network server (515) may be implemented in software on the sender's system, the sender's email server, the sender's gateway, or an intermediate server.

When the sender's email (510) is received by the RPost network server (515), the server determines whether the message is encrypted with message-level encryption. If so, the server (515) decrypts the message using an appropriate decryption method and records the fact that decryption was performed, along with a timestamp, message ID, and other identifiers, as programmed by the server operator. The server then processes the message for delivery to the recipient using the sender's desired level and encryption method.

If the message is message-level encrypted, the server (515) processes the message for delivery to the recipient at the sender's desired level and encryption method. When the message is received or after the message has been transmitted to the recipient, the server (515) parses the identifier and inbound message header data from the message heater data of the last hop, retrieves secure transport information (i.e., TLS v1.2), records the identification of the secure transport protocol information, places the identifier in a database that communicates with the server along with the message identifier and the hop server identifier, and records the secure transport information hierarchically from the most recently received hop. Figure 22 illustrates the types of information the server receives from the inbound message header from the sender that can be parsed and copied to the database.

Emails received inbound from a sender on a server have a series of headers in the order of their last hop (i.e., from the sender to the exchange server, to the gateway server, to the perimeter server service, to the processing server gateway—each of which may or may not have a TLS security level for transport, and each may have different TLS security levels). The processing server records these headers and runs a program on them to parse at least "Last received server name/Secured by TSL (protocol level)" with the option to view previous hops, and if the received message is encrypted at the message level, the analysis is ignored (overridden). In an alternative embodiment, the sending organization can select the view level (last hop, all hops) as a security decision for the last hop only or for all hops. Parsing email headers of messages received inbound from a sender on a processing server can be processor-intensive, so this parsing can be performed after the message has moved through the process to the recipient. The content parsed/copied from the header is placed in a database and categorized according to the hierarchy of importance to the sender's security (i.e., best, acceptable, fail).

After the processing of the email (510) is completed by the server (515), the server (515) transmits the processed message as an outbound email (520) to the recipient according to the customer or user security settings. The message (520) is transmitted to the recipient (525) according to the sender's secure transmission preferences. If the message is processed for message-level security, the fact that the message was re-encrypted by the RPost server is recorded in association with the message ID and encryption method, timestamp, etc. If the message is processed for secure transmission (i.e., TLS), after transmission, the message transfer protocol information is recorded or parsed for details regarding the secure transmission protocol successfully used for transmission (i.e., TLS 1.2) or for other protocols (i.e., HTTP). This protocol information is stored in a database associated with the message ID and the received security information. The parsed/copied message transfer protocol portions placed in the database are classified based on the layer of importance to the sender's security (i.e., Best, Acceptable, Fail).

Referring again to FIG. 21, in boxes (530, 535), the server (515) may be configured to provide an encrypted record of the email to the sender and/or the sender's organization. In this process, the parsed/copied message transfer protocol portions are placed in a database and categorized according to their importance to the sender's security (i.e., Best, Acceptable, Fail). A chart displaying the results (interpretation) and protocol/method data, along with the categories (received from the sender) and (sent to the recipient), is displayed, along with a sum of the security levels (received from the sender) and (sent to the recipient), which may be set to a higher level.

Figure 23 illustrates various examples of one or more embodiments of a process for performing a registered cryptographic analysis on an email provided by a sender or the sender's server. For example, if the parameters received from the sender are equal to "Best" and the parameters sent to the recipient are equal to "Acceptable," the overall result is "Acceptable." In another example, if the parameters received from the sender are equal to "Best" but the parameters sent to the recipient are equal to "Fail," the overall result is "Fail." In another example, if the parameters received from the sender are equal to "Acceptable" and the parameters sent to the recipient are equal to "Acceptable," the overall result is "Acceptable."

FIG. 24 illustrates a table (600) containing various parameters associated with a sender that may be provided by a server to the sender in various embodiments of the present invention, showing the status (615) of messages transmitted from the sender to various recipients (610). In a first example, analysis of the message sent by Bob to Sue provides the following results: (Received from sender) = Best; (Sent to recipient) = Best; resulting in the best overall result. In a second example, illustrated in row 3 of the table, the results for the email sent by Bob to Jimdprp are: (Received from sender) = Fail; (Sent to recipient) = Best; resulting in the overall result of Fail. A report such as that illustrated in FIG. 28 may include data that may later be submitted for authentication.

FIG. 25 illustrates a table showing the status of messages sent from a sender to various recipients (601) that may be provided to the sender by the server, including various parameters associated with the sender (605) and a security report (650) related to the message in various embodiments of the present invention.

Figure 26 is a flowchart illustrating an embodiment of a process workflow (700) that may be performed by a registered encryption process. In box (705), a message is sent from a sender to a recipient via a processing server. The message is received by a processing service in box (710). The process may then branch to box (715), where the received message is analyzed by the processing server, the message header is parsed in box (720), and the received message header information is stored in a database according to the security level and other parameters in box (725).

Returning to box (710), the message is further processed in box (735), where the processing server prepares the message for transmission to the recipient. In box (740), the processing server secures the message for transmission to the recipient. The process may branch to box (745), where the processing server records the fact and method of securing the message.

After the process in box (740), the message is transmitted to the receiver in box (750), and the receiver receives the message in box (760).

Returning to box (740), the system may also record at least a portion of the transmission protocol used to transmit the message to the recipient and store this in a database associated with the server at box (755).

Referring now to box (765), the database may process the database data to determine the security level of the message, and a report referencing the security level of box (770) may be generated. The authentication readiness report may be emailed or otherwise made available to the sender or the sender organization in box (775). In another embodiment, the report data may be submitted for authentication in box (780).

Modified response with AMP HTML email format example

An alternative embodiment uses the AMPHTML email format, which marks the body of an AMP version of an email message, text/x-amp-html, as identified for modification, along with the text marked for modification from links/images in the Plaintext version and HTML version of the email's MIME part. As illustrated by the schematic in Figure 27, an email consists of a MIME tree containing the message body and any attachments to the email. Including AMP in an email adds a new MIME part with a content type of text/x-amp-html (815) as a child of multipart/alternative (800), next to the existing text/html (805) or tex/plain part (810). This ensures that the email message works on all clients. In this embodiment, the text/x-amp-html part must be placed under the multipart/alternative node, and the text/x-amp-html MIME part must be placed before the text/html MIME part. An example of this arrangement is illustrated in the code described below:

In this embodiment, an email client capable of reading AMP email parts should remove the text/x-amp-html part of the MIME tree when a user replies to or forwards an AMP email message, so that the entire message content is modified when replying (the AMP part of the message is not included in the reply), and the targeted content for modification is visible in the message body of the AMP part of the email only, while the HTML and/or TEXT parts of the message remain as described in the previous embodiment for modifying the text designated for modification in the reply.

This is why it is important that the email in this embodiment provides content corresponding to the HTML and TEXT portions that include links to image views of the content tagged for modification, or that the content tagged for modification needs to be placed additionally in an attachment rather than in the HTML and TEXT portion of the message (as per other embodiments described).

Additionally, in this embodiment, content marked for modification in the AMP portion of the message can be set as a dynamic property, for example allowing the content to be viewed once and replaced with replacement content when the message is refreshed, or allowing the dynamic AMP content to indicate to the recipient that the user has read or accepted the message content after which the dynamic content is not displayed to the recipient.

AMP is a technology known for developing ultra-fast web pages on mobile clients. AMP is a set of HTML tags supported by JavaScript that easily enable functionality with an added focus on performance and security.

The AMPHTML email format provides a subset of AMP elements that can be used in email messages. Recipients of AMP emails can view and interact with AMP elements directly within the email.

Additional embodiments with AMP format

Additionally, this embodiment can detect whether the recipient mail client can accept AMP views, and if so, use only the AMP version of the message, completely excluding modified content from the text and HTMP portions of the MIME message format.

Knowledge of a recipient's ability to view AMP formatted messages can be achieved by using AMP open detection pixel tracking, and if AMP content calls for pixels/images, the server can store in a database that this user has AMP viewing capabilities, mark the content market for modification in the AMP version of the message for future messages, and completely exclude the modified content from the text and HTMP portions of the message's MIME message format.

In addition to the registered encryption embodiment, the server may record in a database associated with the message whether the transmitted personal content is in AMP message format and excluded from the HTML and text MIME parts, so that the response content can be automatically modified.

Although the disclosed heat exchange system has been described above with reference to specific examples or embodiments, it will be appreciated that various additions, deletions, changes, and modifications may be made to the described examples and embodiments without departing from the intended spirit and scope of the disclosed systems and methods for preventing accidental disclosure of sensitive message portions of a response and for verifying encrypted electronic message transmission. For example, any element, step, member, component, composition, reactant, moiety, or portion of one embodiment or example may be incorporated or utilized in another embodiment or example unless otherwise specified or unless doing so renders that embodiment or example unsuitable for its intended use. Furthermore, where steps of a method or process are described or listed in a particular order, the order of such steps may be varied unless otherwise specified or unless doing so renders the method or process unsuitable for its intended purpose. Additionally, any element, step, member, component, composition, reactant, moiety, or portion of any embodiment or example described herein may optionally be present or utilized in the absence or substantial absence of any other element, step, member, component, composition, reactant, moiety, or portion unless otherwise specified. All reasonable additions, deletions, modifications, and variations should be considered equivalent to the described examples and embodiments and should be included within the scope of the following claims. This disclosure is limited only by the appended claims.

Claims (15)

As a system for providing a modified response service for email messages,
Includes a server that is remote from the recipient of the email message,
The server includes a processor, a memory communicating with the server, a receiving means and a transmitting means, and the processor is configured by hardware and software programming:
Receive the contents of the email message, including the email message, as indicated by the sender of the email message for correction;
Determine whether a received email message contains content marked by the sender for modification;
Determines whether there are any arbitrary settings set by the sender of an email message that will be used to process the received email message,
Remove the content of received email messages marked for modification according to the determined settings;
Reformat the message according to the determined settings and include information regarding the removed content to prevent the removed content from being included in replies to email messages from the recipient to the sender;
Instructing the recipient to transmit the reformatted message and information associated with the removed content,
A system for providing a modified response service for email messages. In the first paragraph,
The above server is further programmed to store the removed content in a database stored in memory,
A system for providing a modified response service for email messages. In the second paragraph,
The above server is programmed to add viewing restrictions to the removed content to limit various parameters associated with viewing the stored removed content.
A system for providing a modified response service for email messages. In the second paragraph,
The transmitted information associated with the removed content is a link that provides access to the removed content stored in the database by the recipient.
A system for providing a modified response service for email messages. In the first paragraph,
The server is further programmed to add a link to the transmitted reformatted message that includes response control information that limits the content that the response message can contain based on the transmitted reformatted message.
A system for providing a modified response service for email messages. In paragraph 5,
Control information prevents the response from including information associated with the removed content.
A system for providing a modified response service for email messages. In paragraph 6,
The above control information includes information set by the sender.
A system for providing a modified response service for email messages. delete delete delete delete delete delete delete delete