Browse Prior Art Database

A method and system to effectively and easily handle email-attachments.

IP.com Disclosure Number: IPCOM000033925D
Original Publication Date: 2005-Jan-05
Included in the Prior Art Database: 2005-Jan-05
Document File: 4 page(s) / 29K

Publishing Venue

IBM

Abstract

Quite often in our day to day job-related activities we are required to send a number of attachments via email. For example take the case of project deliverables, documentation and other related stuffs. We send these via email attachments to - say a contact person who is at a remote location or to the architect etc and also copy (Cc or Bcc) it to persons in the management . The primary motive of copying the mail (with attachments) to management people is to keep them informed on the current status of the project, to notify them that the respective deadlines has been honored and the project has been successfully completed. However all the people copied in the mail(management people) may not be interested in the attachments. Just an indication that the work is completed and the deadline was honored is more than enough. Sending attachments to all the people is a waste of both mail storage space and network bandwidth. An easy and obvious solution to this is to compose two separate emails one for the persons to whom the attachment needs to be sent and another for those who are interested in knowing the status. But this has one serious drawback. The management people don?t have any concrete proof that the email has indeed been sent to the concerned person/s. This can be taken care if one of the management people sends an email to the concerned person/s and confirm it. But how to decide who will send this mail? If only one management person is involved then no problem, but in normal circumstances the number of management persons involved is more than one. This can result in unnecessary delays and confusions. The solution described here handles the above mentioned problem in a very simple, easy and effective way. All that is required is a slight modification in the way present day email clients send the encoded mail contents to the SMTP server.An important advantage of this method is that appropriate changes are required in the email clients only. No changes are required in the email servers. Also no changes are required in the defined communication standards for email communication.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 4

A method and system to effectively and easily handle email -attachments.

Description

The most common format of an empty email message is To: Cc: Bcc: Subject: < Body>

The "To" field is mandatory whereas "Cc" and "Bcc" are optional. Presently while sending the email from the client to the SMTP server the "To" and the "Cc" field are treated in the same manner whereas the "Bcc" field is handled a bit differently. Simply put, the addresses specified in the "To" and "Cc" field are combined and then identified to the SMTP server using the "RCPT TO" command. After that a DATA connection is opened and the entire message (encoded) along with all the fields ("To", "Cc", "Bcc", "Subject") is sent to the SMTP server. The "Bcc" field is handled separately. More details on the entire process as well as handling of the individual fields can be found in RFC-821 and 822 (www.faqs.org)

In order to achieve our objective what we will do is that we will slightly modify the entire procedure. We will send the entire email message with the attachment to the recipients mentioned in the "To" field, to the SMTP server using the RCPT TO and DATA command. But for the recipients mentioned in the "Cc" and/or "Bcc" field we will send only the plain text part. We can however add a relevant comment to indicate that the attachment is not present.

Please note that we can either use a separate field instead of using the Cc/Bcc field to indicate the email address/es of the person/s to whom we do not want the attachment to be delivered. Only the plain text will be delivered. The "To" field will indicate the address/es of the person/s to whom the attachment needs to be sent along with the email text.

Let us take the following complete example to illustrate what I had mentioned above.

To: user1@in.ibm.com, user2@us.ibm.com Cc: adm1@in.ibm.com, adm2@us.ibm.com, adm3@us.ibm.com Bcc: Subject: Deliverable

Hi,

Please find attached the project deliverables Regards, Pradipta

[Deliverable.ZIP]

The encoded form of only the plain text part of the message is From: user@in.ibm.com
To: user1@in.ibm.com, user2@us.ibm.com Cc: adm1@in.ibm.com, adm2@us.ibm.com, adm3@us.ibm.com Bcc:

1

Page 2 of 4

Subject: Deliverable

Hi,

Please find attached the project deliverables Regards, Pradipta


.

The (MIME) encoded form of the entire message including the attachment is Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="_----------=_10167391557129230"
MIME-Version: 1.0 Date: Thu, 14 Oct 2004 18:00:00 UT From: user@in.ibm.com To: user1@in.ibm.com, user2@us.ibm.com Cc: adm1@in.ibm.com, adm2@us.ibm.com, adm3@us.ibm.com Subject: Deliverable

This is a multi-part message in MIME format.

--_----------=_10167391557129230
Content-Transfer-Encoding: binary Content-Type: text/plain

Hi,

Please find attached the project deliverables Regards, Pradipta --_----------=_10167391557129230
Content-Transfer-Encoding: base64 Content-Type: application/zip; name=" Deliverable.zip"

UEsDBBQAAAAIAEAUmicKJJts5...