Forward Link Reverse Retrieve Mail
Protocol
(FLRRMaP)
A Completely Spam proof Email Protocol Overview
Executive Version
Mark A. Mollenkopf
July 2007
Mollensoft Labs, Sierra Vista AZ.
1. Introduction
The objective of the Forward Link Reverse Retrieve Mail Protocol is to totally eliminate Spam distribution and proliferation throughout the internet while simultaneously improving security and reducing aggregate Internet bandwidth consumption. The protocol is highlighted by the following key features:
• A “Pull” method versus push for retrieving the email body and attachments
• Spammers cannot send from fake address (domain spoofing) because domain part must be resolvable in order to retrieve the email body
• Secures Mail access by using One-Time cipher, encrypted authentication retrieval sessions for the email body typically over SSL/TLS Socket Connections
• Places the burden of payload delivery on the spammer rather than simply using open internet relaying to bear the delivery of their information
• Internet-wide bandwidth usage is significantly reduced because only the email stub is sent via SMTP and most spam email payload retrievals will not occur
• Senders servicing Mail Server (Link Server) domain must match MAIL FROM domain unless proxy sending domain is noted in DNS and added to FLRRMP Server’s whitelist
• “Bolt-On” technology leaving core mail transport mechanisms in place (SMTP/POP/IMAP)
• Can Operate side-by-side with existing protocol standards while migration to complete implementation takes place
• Forces Spammers to “hang around” on a valid domain in order to ‘deliver’ message payload resulting in easier identification and subsequent prosecution/blacklisting
Email is an abstract application transport or use of distributed communication where information can be transferred between system processes throughout an ever converging array of dispersed network architectures. Email messages are transmitted by relaying data through a process connected to two (or more) networks. Since emails containing various malicious or unwanted data can be relayed between hosts on different transport systems this new protocol ensures discreet security precision of payload delivery while denying the delivery of payloads from insecure or malignant sources.
2. The FLRRMaP Process Model
The FLRRMaP design augments the existing SMTP/POP/IMAP email delivery and retrieval process where SMTP is used to send email from one host/user to another and the recipient endpoint client retrieves the email using POP/IMAP type email client protocol. When the FLRRMaP protocol is added to the existing email protocol there are several significant changes to the delivery and retrieval process. These differences are what enables the enhanced security, removes all spam and reduces network bandwidth consumption. This process is briefly detailed below:
Example One, A FLRRMaP Modified SMTP server performs the reverse retrieval on behalf of the recipient email client so no modification (beyond the SMTP/FLRRMaP process) to the recipient client protocols is required.
A. Client “A” Sends a complete Email via SMTP protocol to its servicing MailServer Port 25 (myorg.org is the servicing SMTP server for Client “A”)
B. The myorg.org SMTP server forwards only an Email Stub to the email recipient(s) SMTP servers and creates a unique stub for each recipient.
C. The servicing, recipient(s) SMTP server(s) (Client “B” in this case) downloads the email payload (reverse retrieval) by following the FLRRMaP encoded URL within the received SMTP stub.
D. Client B’s Email Client downloads the mail using a standard POP3/IMAP protocol and is unaware that the FLRRMaP protocol prosecution occurred.
Example Two, the email client performs the reverse retrieval of the email payload:
A. Client “A” Sends a complete Email via SMTP to his servicing MailServer Port 25 (myorg.org is the servicing SMTP server for Client “A”)
B. The myorg.org SMTP server forwards only an Email Stub to the email recipient(s) SMTP servers and creates a unique stub for each recipient.
C. Client “B” downloads the email Stub via POP/IMAP/Other protocol from its servicing email server (currently the standard process)
D. Client B’s Email Client downloads the SMTP Stub and proceeds to download the complete email payload from URL specified in email stub using FLRRMaP Protocol (follow the secure URL in the Stub)
3. Email Stub components
The email stub is the only item that is sent across the network as the email payload (body) remains housed on the originating SMTP Server. The email body is retrieved by following the FLRRMaP encoded URL which contains several security measures including a one-time, encrypted authentication parameters enabling the recipient to download the email payload (body).
The critical component contained within the Email Stub is the URL which describes the network path to the message stored on the sending email server and further describes how the message is to be retrieved by the recipient email client (or recipient’s servicing SMTP server). The URL includes a retrieval protocol definition in addition to the resource location pointer defined by two hashes which the originating server will combine and determine the location of the specified email body on it’s file system (or RDBMS). Most importantly, the URL contains two authentication keys which are only valid for one successful retrieval session. The diagram below illustrates the Email Stub Components in brief.
4. Summary
In Summary, the FLRRMaP protocol completely eliminates Spam while simultaneously improving security and reducing aggregate Internet bandwidth consumption. Immediate, internet wide implementation of this protocol would undoubtedly result in a more effective and significantly more efficient Internet. Of the two variations, implementing the FLRRMaP protocol on the Servicing SMTP servers would be the easiest to implement as it would be largely transparent to the communicant end point clients.
5. Point Of Contact
I am submitting this protocol description forward for peer review and welcome any comments. This overview document can reviewed at: http://www.mollensoft.com/FLRRMaP_Protocol_V3.htm
Mark Mollenkopf