Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method to provide an enhancement to an email server's functionality by utilizing "sticky" bbc email addresses on all subsequent responses to a given email message in a clandestine way.

IP.com Disclosure Number: IPCOM000199094D
Publication Date: 2010-Aug-25
Document File: 2 page(s) / 22K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method for allowing bbc-ed recipients of an email to receive all subsequent responses to the original email privately.

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

Page 1 of 2

Method to provide an enhancement to an email server 's functionality by utilizing "sticky" bbc email addresses on all subsequent responses to a given email message in a clandestine way.

Currently, sending an email message with the bcc filed populated does not result in bcc recipients receiving all consequent responses to the original email. The method described here offers a convenience when the entire chain of email responses needs to be automatically and confidentially forwarded to selected email recipients, without other recipients receiving the responses. This feature would not apply to responses to an email message which was forwarded by any of the original recipients.

Method 1:


Require the email server to attach to each email, a base64 encoded block of encrypted text containing the list of "sticky" bcc recipients.

The bcc field would be encrypted and decrypted using server's certificate.

Because of the encryption block being of constant size,there would have to be a limit to the total number of characters taken up by all email addresses in the bcc field. The email server system should guarantee a known maximum number of bcc email addresses that may be provided.

Method 2:


Implement the bcc-tracking logic on the SMTP server.

Method 2 would not impose any limits on he number of bcc-ed email addresses. Carrying the sbcc addresses in actual email messages as described in method 1 could be still useful if various

participating vendors' servers understand how to interpret such contents. This could be an option

in case direct server to server querying of the sticky bcc addresses is not possible. It could also make the feature more easily adoptable by different email server vendors.

The method requires the email system to be able to define and execute the following logic:

Implement the bcc tracking logic on the server or within a special block (attachment) of the

1.

email message itself - for example using XML. (See method 1 vs. method 2 above)

When any recipient responds to the email with bcc field populated with new addresses, the

2.

new bcc email addresses are appended to the already provided list of bcc addresses and from this point on all subsequent response emails will be received by all bcc-ed recipients.

If any bcc-ed recipient of the original...