Browse Prior Art Database

A method and system for mail validation

IP.com Disclosure Number: IPCOM000248852D
Publication Date: 2017-Jan-18
Document File: 7 page(s) / 229K

Publishing Venue

The IP.com Prior Art Database

Abstract

With the rapid social development, Mail has become a necessary channel of the most important tools connecting to different entities. Many enterprises are using the Mail as the first application to issue orders or information through it, either communication within the company or outside. And the employees use to back up the history mail into personal information library for future reference. Obviously, the security in exchanging information with Mail will no doubt take a highly key role in defending the attack from outside.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

1

A method and system for mail validation

With the rapid social development, Mail has become a necessary channel of the most important tools connecting to different entities. Many enterprises are using the Mail as the first application to issue orders or information through it, either communication within the company or outside. And the employees use to back up the history mail into personal information library for future reference. Obviously, the security in exchanging information with Mail will no doubt take a highly key role in defending the attack from outside. A conversion or event with Mail application always generate multiple history records in the whole mail chain, eg, communication with reply mail, forward mail. When a mail reaches to a user at any time, the history mail attached in the latest mail is always there as the original text. Some of us don’t want the attached history mail to be tampered before it reaches to them. Otherwise, this would cause a big trouble in personal informational asymmetry, even a risk to the whole company if the user is an employee. However, we don’t have a good method to prevent the history mail from being tampered. In current Mail application, the history mail can be allowed editing in either way, reply or forward basing upon the original mail. Of course, sometimes we need it to be editable since the following sender really wants to replay something based on the last copy. But we don’t see any mail application can defend the history mail tampered since some of users hope we can offer them the feature. Also during the mail communication within multiple services, a common situation is that not all of information in history mail is important, and not all of them is innocuous. Both of them are meaningful to users. Our disclosure will propose a flexible method to implement the requirement from users in both of ways, especially for the part of tamper detection against history mail. And we can make it possible to update the editable part in history mail dynamically as a supplement even if the mail has been received by the following users. Besides these, the feature is maintained and protected with cloud collaboration running with all senders/receivers in the whole mail chain. In general, the original mail is always the information source in the whole mail chain. This will no doubt be protected as the most important part. Our solution will enable the original sender to decide whether the outgoing mail is editable when it is replayed. And it can provide him to customize the editable part. The customization function can be select any text, picture, even a word. Not only does it makes it be controlled by the original sender, but the customization restriction setting can be passed through the whole mail chain, then the following users can get them background but don’t have the rewrite authority to tamper either the history mail or the customization restriction setting defined by the original sender. Thus all the fo...