[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Asrg] 2 - Solving Spam By Establishing A Platform For Sender Accountability



Overview of Email Sender Validation Effort to reduce SPAM:

 

Efforts to validate the sender of an email message will help reduce the dissemination of unwanted email. We propose a specific methodology to address this issue by using a simple method based on a process that responds to a new message with specially coded request for validation message.  This specially coded message is sent to the “reply to” address.  The message initiating mail server receives this reply and responds with an acknowledgement to the recipient mailer server if the initial message was indeed sent from this server.  Otherwise it does not respond.  If a positive response comes back the initial message is transferred from a pending directory to the recipients directory.  If there is no response in a parameter based time period the initial message is discarded by the recipient mail server.

 

Here is a more detailed, but simple, example of how we propose the solution work:

 

User A uses his or her MUA to send a message to User B.  Server A sends the message to Server B.  Server A runs a standard MTA process and that transmits the message.   A copy of the message header is stored on Server A to match against a validation effort.  Server B receives the message through the standard MTA method but all messages go into a pending mail directory (PMD).  Another process called mail validation agent (MVA) manages the pending mail directory. 

 

Server B’s MVA reviews incoming messages in the PMD and sends a request for validation (RFV) to the sender for each new message via the standard MTA of Server B. The file name of a message that has an RFV outstanding is changed to differentiate it from new messages.

 

The RFV is a standard message that contains some specifically defined elements to allow the process of verification to work.  The RFV contains a random string that is associated with the initial message’s file name.  The RFV also contains details for Server A to validate that the message was sent.  A piece of the message is purposely not sent to Server A so that it gets added to Server’s A response to the RVF and provides additional legitimacy to the validity of the message.

 

Server A receives the RVF and places all such messages in a specific mail directory.  A process manages RVF’s on the server.  This process on Server A validates the RVF.  If it is valid, that is there is a match to the stored header; the process on Server A sends a response to validation request (RVR).  Server A deletes the stored header. This RVR is returned to Server B and proceeds to manage the “valid” message.  If Server A does not find a match to the RVF, then no action is taken. 

 

Stored header information for matching is cleaned up from a sending server based on a parameter driven period of time.  This could be several days to account for a recipient’s server being down.

 

If there is no response to the RVF, within a parameter-based period of time, the message is discarded. 

 

This is a rough draft of the concept without too much detail in terms of actual implementation. 

 

Comments would be appreciated.

 

 

 

Howard Roth

The NetTech Group, Inc.

11 Airport Blvd., Suite 200

South San Francisco, CA 94080

Phone - 650-871-7209

Fax - 650-871-7219

Email - hroth@tngi.com