Browse Prior Art Database

Method and system for secure and transparent attachment handling

IP.com Disclosure Number: IPCOM000244525D
Publication Date: 2015-Dec-18

Publishing Venue

The IP.com Prior Art Database

Abstract

This article describes a method to handle the email attachment on a central storage so that email users can receive/reply emails without having to send the attachement along with the email body. This can reduce the overhead of storing duplicated attachments in each email recipients inbox.

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

Page 01 of 12

Method and system for secure and transparent attachment handling

Email is an important communication tool for the modern office workers. However, email attachment has bring several issues to the existing email system due to the design. In the current design, email can be divided into a number of email headers and an email body. If there are attachments in the email, the attachments will be encoded as part of the email body with the MIME standards. Email size will increase significantly if there is large attachment file in a email body.

As a general observation, most of the disk space for an email account is consumed by the large attachments in the emails. To make things worse, if there is a large attachment file in one email, and there is a long thread of emails for it (and no one removed it in these follow up emails), then every follow up email will have same large attachment file embedded, which will soon eat up the email quota. To sum up, the following three factors contribute to the problem:

1) The large email attachment files will increase email size, and may get rejected from sending out by the mail server.

2) Duplicated email attachment files in every follow-up emails (If the sender did not remove the attachment before he sent/replied);

3) If a email with large attachment file is sent to multiple recipients, every receiver will get a copy of the same large attachment file in his inbox;

The fundamental reasons for such issues are due to the design of email systems. There is no special handling for email attachments in the current design, and email attachments are handled just same as even text paragraphs in a message body. However, with the pervasive adoption of email systems set by the several standard protocols (SMTP/POP3/IMAP or S/MIME), the new design should have to still keep compatibility with these protocols and provide a seamless integration with existing systems.

This disclosure describes a method & system to solve the above 3 issues with a hybrid email system design.

In this invention, a new method and system to handle the email attachment is proposed. Before sending the email, the attachment will be uploaded by email client (MUA) to a attachment storage system (ATS), and an external accessible URL will be returned to the email client (MUA). And then a block of meta data will be created based on the URL and other attributes of the attachment file and this meta data will be inserted into the email body and get passed along the email routing path. A security mechanism in ATS will ensure ONLY the valid email recipients will have read access to the attachment but none will have write/modify access to protect the integrity of the attachment. So that all the email clients of the email recipients can automatically retrieve the attachment from ATS based on the meta data block in the email body.

This design has a few advantages over existing solutions:

1) It will solve the duplicated storage of attachments from a system p...