New Page 1

Simple Mail Bag Security Protocol rev. 06b Draft 5

Oct. 28, 2002

by recommendations of the National Security Coordinator
American Computer Scientists Association Inc.
6 Commerce Drive, Suite 2000
Cranford, NJ 07016
908-931-1390
homepage: http://www.acsa.net
questions to: mailbag@acsa2000.net

Summary: Simple Mail Bag Security Protocol, a simple means to cause end-to-end verification of sender to receiver, and delivery of email by sender's actual mail server and to receivers only legitimately associated with a particular receiving server. SMBSP lends itself well to a new, higher class, higher quality of email service, called eMailBag Services. Because any impersonation, header forgery and/or flood or DoS email destination services in an SMBSP authority chain can be blocked and/or authenticated/verified, accountability at both ends of an eMail transfer is maintained. Once accountable, neither Mail Servers nor end point Senders are going to wish to be found engaging in knowing virus Spam insertion, deliberate flooding, and Bulk Anonymous emailing, which by the way, would be essentially impossible and improbable from the "anonymity standpoint.". This White Paper is in Draft Format, and it's contents are the property of the ACSA Inc. Those seeking commercial reproduction may call ACSA at 908-931-1390 at normal working hours.

1.0 Purpose and Justification.

SMBSP is not a SPAM panacea. With the advent of stealth mailers and forgers, it is mainly the responsibility of the major domains to eliminate forging of their identities by cooperation. Then, it becomes the responsibility of filters used on existing accounts, to eliminate "chaff" in the form of private mail sent from such stealthy mailers and forgers that does not impersonate a major domain mailer.

SPAM is a very painful byproduct of the failure in the design of the web, to provide simple means for companies to advertise their products. As a result, people resort to bulk SPAM mailing for the purposes of hopeful promotion of their products. Unfortunately, too much SPAM is being also used to engage in fraud and very poor quality promotions, causing a byproduct of harm to legitimate businesses who engage in Bulk Unsolicited Email Advertising (BUEA).

It is estimated that in commercial inboxes, the SPAM outnumbers the legitimate email by about 27:1, once a company's email box is known to the web, it gets harvested and is perpetually deluged by SPAM mail. This causes an enormous burden not only to the Mail Servers, which have to store and process the SPAM, but causes unnecessary loads on ISP access points, (ISP/APs are all points where a user may use his or her Browser and Mail Reader), and worse, on the unwary company or individual who must filter through all the SPAM to try and find legitimate correspondences.

We have estimated that as much as 1/3rd of the time spent processing mail (typically as much as 20 minutes per day per mail account) is spent eliminating SPAM or bypassing it. That 20 minutes, multiplied by million upon million upon million of home and corporate email account, is literally draining global labor effectiveness at an alarming rate.

It also leads to flood inaccuracies, and other activities, such as VIRUS insertion, that make it all the more imperative that every email be associated with it's sender, and that no further forging be allowed. Arguments about anonymity and privacy violation caused by such a policy are, quite simply, SILLY, since the party who creates an account has full discretion as to the identity he or she wants for a mail account, and full discretion about the displayed name on an email. Since the account to which the email is bound is protected from examination by the public, and since no one would be able to successfully forge their identity, SMBSP is actually an ADVANCE in that it eliminates electronic email impersonation by either disabling it, or making it detectable and prosecutable.

2.0 Implementation Highlights.

The SMBSP operates in the Space between the Sending Mail Server and the Receiving Mail Server, and between the Sending Mail Server and the account holder sending the email using send mail or other sending agent. It implements the notion of a "Mail Bag" (a grouping of email), a "Send Server" (the party transmitting the Mail Bag for distribution) and a "Receiving Server" (the party receiving the Mail Bag to distribute to it's users).

Rule Number 1: The First rule imposes a first level of authentication, "All email must be From: the logged in, authenticated user account who sends it". NO SMBSP authority Server may accept an email item to send, whose FROM: field does not accurately reflect the Account name and Domain Server of the Account Holder who is sending the email, and an optional password. That includes any email being sent by a Server, which must assign the master account for that Owner of the domain, and it's password, and give that same master account (or an authorized email account within that domain, for multiple username accounts) or that mail will be dropped. That includes any individual sender sending directly from a differentiated point of access, who must use the account name and password for that username, to send with a FROM: field that reflects that sender's identity. Reply-To is available for commerce packages to use if they wish to place a subscriber's or customer's email identity for return email, in a form that they forward for processing.

Rule Number 2: The Second rule imposes the last level of consistent authentication, "No email will be distributed to anyone other than someone explicitly listed in a To:, Cc: or Bcc:, and the To shall never be hidden." All mail that does not list the receiving address in one of these fields in the incoming Mail Bag, shall be deleted by the Recipient. This eliminates all other means of addressing, wrapper or distributing email. No broadcast addresses shall be accepted.

Rule Number 3: The Third rule imposes a first level verification, "Verifying an Alleged Send Server". All SMBSP authority Servers must adopt SMBSP Confirmation Protocol. This includes a verification sequence when asking a Receiving Mail Server to accept an email, called a "Mail Bag Confirmation ID". It is sent back by the Receiving Mail Server to the registered IP address/port of the alleged Sender's alleged domain name for confirmation. This phase is called "Alleged Send Server Verification".

Rule Number 4: The Fourth rule imposes a second level verification, "Verified Send Server Authentication of Alleged Mail Bag". This is where the Receiver accepts the Mail Bag from a Verified (no longer alleged identity) Sending Mail Server (an SMBSP email or group of emails is called a Mail Bag) and commences to verify it's authority to be processed granted it by the Verified Sender. requiring the Receiver to maintain a public PGP key, which the Sender uses to encrypt a Master Mail Bag Memorandum, which includes confirming information about each email. The Sender and Receiver's keys are stored by a special Key server maintained by the ACSA, that confirms the origination of each key being from the SMBSP of the authority Server in that Mail domain. The Sending Server receives the MBCID along with an internal encrypted MBCID, encrypted in it's public PGP key, which it must acknowledge to the Receiving Server, before the Receiver processes the Mail Bag further. The Receiver decrypts the incoming credentials using it's private key then encrypts the received "credentials" in the alleged Sender's public key and returns it to the Sender, who must acknowledge it in appropriate fashion after decrypting it using his private key. Along the way, the Sender and Receiver each include a random string (the so-called currency token) within the credentials packets sent back and forth in the mutual and bi-directionally encrypted fashion, one in each direction, so that each can verify that the alleged sender and alleged receiver are the actual sender and receiver, respectively and that the sender acknowledges transmission of the Mail Bag, and the receiver receipt of it. In the event that any error or redirection is detected, the entire Mail Bag is DISQUALIFIED. It is the sole responsibility of the alleged Sender to determine what to do about a DISQUALIFIED Mail Bag, if anything. [ A corollary function of Sender Responsibility is to notice violation of limits on copy count, and deliberate inclusion of any recognized virus content. As such, Software Providers in the field could team with existing Anti-Virus solutions to enable the SMBSP authority Server to include outbound mail virus block, so as to eliminate the volume of such eMail entirely from an SMBSP class of service. Other behavior patterns consistent with viruses operating within a user's PC could be detected, blocked and a user forewarned that their PC might be infected. A second check on the Receiving SMBSP authority Server could also implement a redundant check for embedded virus signatures. These optional components involve commercial software providers such as Norton, McAfee, Solomon, Trend Micro, Panda, VBuster, Grisoft, and a host of others. Upon release of our "snap in" components for NT based and Linux/Unix/Solaris/AIX based servers, the Association will be providing a fully documented API for use by AntiVirus providers locally, to include linkage to their packages for those Server systems, so they may include that function within their Mail Scan repertoire for their Service Provider Customers. {subject to relocation to implementation specifics in next Draft} ]

Rule Number 5: If an SMBSP authority Server sends a MailBag through to an SMBSP authority Server with improper credentials, or fails to acknowledge a MailBag's transmittal by credential failure or decryption failure or private currency token failure, on either party's part, that MailBag is automatically discarded as "DISQUALIFIED". Repeated transmittals of fallacious MailBags that are confirmed to have come from a particular IP Address/Port, allows a recipient to issue a Boycott message to a sender, and cease accepting any further MailBags from that server until arbitrating a solution to the problem..

Rule Number 6: SMBSP authority Servers that take a MailBag, alter their contents and remail them to a third party, are automatically disqualified from use of SMBSP and are placed onto the PERMANENTLY BLOCKED LIST. This list must be updated in real time by downloading it from the PERMANENTLY BLOCKED LIST SERVER by SMBSP authority Servers and any email that such SERVERS transmit, simply discarded. Only the Master Authority for that List may create the list for downloading. The List is transmitted to a Mail Server only if that Server is registered in the PGP Key table inside of the SMBSP Key Server.

Rule Number 7: SMBSP Key Servers are similar to ordinary PgP servers except for their means of operation. To obtain a key, the senders and receivers must obtain their key pair by registering with the SMBSP Key Server. The key pair, which is periodically updated, is generated BY THE SMBSP Key Authority.

3.0 Implementation Specifics.

Benefits of adopting Rules 1 through 7.

a) Authenticity of Sending and Receiving Mail Servers is assured. Because of the ability for the Receiver to verify the authentic nature of a Sending Server's IP address and it's registration through the SMBSP Key Server, at the very least, the sending server and receiving server know that each other exists, is real, and has registered with the SMBSP/KA (which includes a list of authenticated mail To and From domains that each is allowed to handle Mail Bag contents for).

b) Contiguity and Genuineness of the Mail Bag and it's contents can be verified, and authenticated by the Sender to the receiver. Since in order to send to someone an SMBSP Mail Bag a sender must obtain a copy of the current public key for that receiving Mail Server, which the Key Server will block for all Disqualified/Boycotted/Blocked Identities, preventing them from being able to mail if it is determined that their actual IP was responsible for a multitude of violations other than those caused by impersonation of them.

c) Authenticity of the Account Holder who sent eMail inside of an SMBSP Mail Bag, is guaranteed by the Sender, who must maintain either simple Username Password Authentication, UPA Auth with Login UPA Auth (e.g. - the Access Session to that User's ISP Access Account AND the eMail UPA Auth must match EACH OTHER as well as the Mail Server's records) or UPA Auth with Login UPA Auth AND Secure EMailer Login Protocol. Henceforth, since only that Account Holder, or an authorized "additional Username/Password" pair for that registered Account Holder, may be used and only the authorized usernames for that Account may appear in the FROM: field of the eMail, the identity and accountability of the original sender is maintained.

d) Delivery of an email to a Receiving Mail Server in a SMBSP Mail Bag that bears no corresponding To, CC, or BCC that references one or more legitimate delivery names who, in the same way as the Sender, may only be delivered email if it precisely matches their username/domain, leads to discarding that entire Mail Bag, and repeated so doing in a period of time, might cause the Sender who is incautious, to cause himself to be boycotted (temporarily) at the Receiver's end. To prevent this Senders must be prepared to analyze a return notice generated by the Receiver, that identifies the eMails that have 'No Destination'. Now, obviously, if people leave general delivery addresses open on their Mail Servers, that opens up the possibility that this provision will not work as to their Mail Server. But, nonetheless, they should observe stringent rules, and generally only eCommerce oriented servers leave general delivery account rules on their server.

All told, impersonation of someone by someone else on the web would become very difficult, mail servers would have a simpler means than Digital SSL or Certificates to prove they are who they say they are (not at the IP in question, you'll never get the keys to encode/decode with), and bulk mail packages would simply reject.

One attribute of the SMBSP Mail Bag is to provide both SMBSP Class and Unverified Class of mail on the same server. This would allow for the questions concerning privacy to be resolved where both parties to such Unverified mailings to allow transmittal of such mail.

In that case, the Mail Service Provider would provide to his user, a different subdomain for receipt of the Unverified Class.

Naming conventions are proposed in the implementation section, however, to summarize:

Virtual Mail Server Nomenclature

SMTP/SMBSP Class Server or PopX/SMBSP server: mailbag.domainname.com
SMTP/Unverified Class Server or PopX Server: mail.domainname.com

Specific Mail Server Nomenclature

SMTP/SMBSP Class Sendmail Server: mailbag.smtp.domainname.com
SMTP/Unverified Class Sendmail smtp.domainname.com

PopX/SMBSP server: mailbag.pop3.domainname.com
PopX Server: pop3.domainname.com

This would allow traditional mailing to run concurrently, but would require one to set up an account for both styles. The HTTP form of Web Mail Server could equally be updated with the added flexibility of it's HTML based user agent providing simple checkbox for setting whether to always send through SMBSP Class or to send through Unverified Class, or allow him to decide at send time. It seems likely that the sub domains would represent virtual entries to the same Mail Unit, with separate queues and rules for each class of Mail Service.

The user agents would not need serious modification, because most of them can accommodate the requirements, the users would still have adequate flexibility to do either form of mailing, but they'd have to be prepared to cope with the consequences of doing a Bulk Mailing to the SMBSP Mail Server, since the upgraded Mailer software in use might bounce his or her account.

The Transition period of implementation to give SMBSP Protocol a chance to be implemented and catch on, would run concurrently to the Unverified Class using current protocols.

Such could last from 1-2 years, until general consensus was that all remailers and mailers were adoptive of the SMBSP Protocol. Once adopted, gradually the implementers could put away all Unverified Class servers.

Remailers and Mail Firewall Intermediaries are a special case that will be addressed in another section of this document.

Auto responders might require some modification in order not to respond to bogus mail through the SMBSP channel, they'd have to respond in kind to each incoming mail.

Perhaps unverified mail as a "class of service" could be kept in use for generalized mail purposes such as Newsletter mailings, and receipts from Mailing List / Major Domo servers, by the Web Citizenry for an indefinite period of time.

One of our scientists is the original developers of what we know today as Internet Email. He would recommend that the unverified class be eventually categorized as "Junk eMail" so that those who liked it, could still use it for various commercial or social purposes (e.g.- as an initial form of contact when contacting parties on a Dating Service, etc.). However, the junk class that current eMail servers implement as their only form of eMail is very unduly risky, and very difficult to justify, since it opens up doors and households to predators, frauds, and other forms of unaccountability.

Inevitably, impersonating ISP Access Users for the purposes of using their identity to engage in Verified Mailings by unaccountable third parties, will need better security so as to afford protection against "Far End Invasion" of someone's identity.

FURTHER DRAFTS ARE BEING COORDINATED FOR COMPLETION BY THE SECRETARY OF THE AMERICAN COMPUTER SCIENTISTS ASSOCIATION INC. and will be published within 30 days.