INTERNET-DRAFT Rafael Skodlar This document is an attempt for Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Category: SMTP [experimental] Created: 2002-06-29 Expires: when spammers give up :-) Note: Under construction AMTP - Advanced Message Transfer Protocol Status of this Memo This document specifies an Internet standards email exchange protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of RFC 821, RFC 822, RFC 1870, and other "Official Email Protocol Standards" for status of current protocol. There is no restriction on distribution of this memo. Note that this memo is a work in progress. Abstract While other protocols such as RFC 1830 and RFC 3030 provide means for transferring large amounts of data as part of email, main objective of this draft is to provide a description of a protocol for reliable means to exchange electronic mail and minimize the possibility for delivery of UCE (Unsolicited Commercial Email). This protocol, which limits the amount of information exchanged during first contact, would practically eliminate the incentive for UCE and give users full control over this form of electronic communications. Currently, many email handling systems are configured to use lists of known UCE violators, commonly known as RBLs (Relay Black Lists), in order to stop the communication before the undesired messages enter the server, or use software to filter the contents of the message checking for specific words based on language and grammar rules. It's a never ending cat and mouse game where UCE violators keep changing the tactics (misspelling and adding random characters in the message for example) and the service providers who are trying to prevent such abuse. Nevertheless, legitimate users of email are on the losing end. While some attempts have been made, no legislation will ever be able to control the type of electronic email because abusers are known to ignore the current laws and because of the border-less nature of the Internet where laws in one country do not necessarily agree with the laws in another one. Comments Public comments can be sent to email address listed in http://www.linwin.com/email-protocol/index.html. It is assumed that senders MTA is not Black Listed on the Internet or locally on linwin.com email server. While this memo describes a protocol which restricts first time email communication between the two parties to an exchange of email envelope only, it includes means for standard email exchange described in RFCs prior to this publication for backward compatibility during transitional period. Depending on configuration, this is a "challenge and response" type of protocol with smallest possible inconvenience to email users. It's important to note that email flow control is in the hands of end users and not email providers. Email users may choose to use server default configuration with minimal restrictions on email, or they may select from numerous options to handle the flow and type of messages that meet their requirements. Terminology used in this document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. Definitions MUA: Mail User Agent (mail tools such as pine, mutt, Firefox, Eudora, Outlook, or Ximian, used by the end users) MTA: Mail Transfer Agent (as used prior to 2003 and present) CMTA: Control MTA, proposed new type of server IMTA: Intermediate MTA, a proposed new type of email server. It is an optional type of transfer server with a subset of CMTA functions FW: Firewall (Network security device) R. Skodlar et. al. Table of Contents 1.0 Introduction 2.0 Description of email exchange 3.0 Handling atachments 4.0 Transition to advanced system, considerations 5.0 Potential Problems 6.0 Summary 1.1 Introduction Electronic mail exchange over the networks traditionally mimics flow of standard letters and packages handled by postal and courier services. The sender's MUA delivers the message to their local email server which in turn sends it to MTA at the recipient's service provider (RSP). RSP checks recipient's address and accepts it if appropriate. Based on MTA configuration, additional checks are done but are not important for this discussion. Although SMTP is widely and robustly deployed in the Internet community, it's protocol allows for abuse with unsolicited email on a massive scale. While current email protocols provide means for marking email messages such as advertising or bulk email, most people engaged in unsolicited email activity ignore that feature and simply abuse the system. There are many systems with content-based filters but they can't distinguish spam from legitimate mail with sufficient accuracy. A short memo with a URL is all that's needed to deliver unsolicited message. Most UCE detecting systems fail on such messages. This memo uses a mechanism described in section [2.0] which allows for better control over how email gets routed between the users and intended recipients. Depending on configuration, it provides transparent transition from the old system for those who want to preserve it for some reason. With proposed protocol system administrators select basic configuration mode based on company policy for email servers. Systems may be setup to accept email the same way as it has been done untill now (2003), including checking for dangerous payloads, or enable options described in new protocol. 2.0 Email exchange using old, new, and mixed MTA systems. Mail Forwarding --------------- The following ASCII pictures show standard components used in email communication exchange as well as advanced MTP. 2.1 Typical email exchange using Standard Mail Transfer Protocol is shown in Figure 1 ------- ---------- ---------- ---------- ------- | | | Server | | Server | internet | Server | | | | MUA |---| MTA |-FW--| MTA |----//-------| MTA |---| MUA | ------- ---------- ---------- ---------- ------- Fig.: 1 Email user delivers a message using MUA to the nearest MTA which then routes it to the appropriate servers to reach the recipient. If the recipient's email address is not correct, or they reject email for whatever reason, the messages goes back to the sender. Since the sender is not always verified at originating MTA, undeliverable email gets stuck in the "middle somewhere" which causes problems to email administrators who cannot send it back to the sender. UCE is mostly delivered from systems that act as an outgoing MTA, without accepting any bounces. Such MTAs disappear completely after delivering UCE. In many cases, systems acting as MTAs are only victims of break-ins acting as "zombies" while their owners don't even know about it. 2.2 Email exchange between Advanced mail service systems is shown in Figure 2. AMTP - Advanced Mail Transfer Protocol ------- ---------- ---------- ------- | | | Server | internet | Server | | | | MUA |---| CMTA 1 |----//-------| CMTA 2 |---| MUA | ------- ---------- ---------- ------- Fig.: 2 CMTA server (Control Mail Transfer Agent) is a system non-stop connected to the Internet. It keeps configuration information about legitimate users allowed to use it as a relay, their email and messages they sent out to first time recipients. Non-local first time recipients pickup messages from senders through their CMTAs. If the recipients do not pickup the messages, senders get notified after expiration time. Scenario 1: a user wants to exchange email message with recipient(s) for the first time with indication of interest for subsequent exchanges. User's MTA delivers the message to advanced email server, CMTA 1 including a flag for possible ongoing relationship. If the user is authorised to access this server, the server creates a key based on sender and recipient's address, adds it to the envelope and sends it to the recipient's server, CMTA2. The body of the message is kept in local queue on CMTA 1 for pick up by the recipient's CMTA 2 at recipient's convenience. The recipient(s) receive envelope only and make a decision about the message based on the sender's address or subject line. If they decide to accept the message, they indicate their interest with a flag which is sent to CMTA 2 which in turn sends it's own key based on recipient and sender's address with the request for the body of the message to CMTA 1. The message is then delivered to those recipients that indicated they want to accept the message. The recipient's flag may indicate the frequency of messages to be accepted from the sender. For example, it could indicate a one time acceptance only, multiple times, or indefinite. If the recipient ignores the envelope and never responds to it, their inaction triggers time out on CMTA 1 to return the message to the sender. Both servers keep keys generated one either side for future communications between two users. The keys are kept on these two servers and could not be used by a third party. They could be revoked by either party at any time. MUA would provide means to manage the relationships user wants to keep with others. If one of the the recipients is not interested to pickup the message due to the subject line of the envelope or sender's address, the message never gets delivered and it is up to CMTA 1 to notify the sender of that status after the expiration time. When the recipient decides to communicate with the sender on a regular basis, he indicates that with the flag on his request to CMTA 2 to pick up the body of the message. CMTA 2 sends a key or token to CMTA 1 that is known to these two servers only and is used for the next mail exchange without the delay, i.e. CMTA 2 takes the following message including body of the message without a delay. A trust between the servers is established on per user basis. While this system introduces a short delay in the process of first time email exchange, it completely prevents delivery of undesirable messages. First time sender can only deliver an envelope with limited size subject line. Evaluating envelopes based on sender addresses and subject lines would be much easier than filtering whole messages. The system provides means for creation of a "white list as you go". It requires servers to keep track of individual's keys and relationships. That would be more effective than trying to match sender's address or domain names and parse the message body for strings in all kinds spelling combinations or languages based on ever changing rules or AI. Scenario 2: user sends message to the recipient with an established relationship. CMTA 1 accepts the message from the sender, adds a previously generated key to the envelope and connects to CMTA 2 which in turn compares the sender's address and a key in it's database and accepts the message for delivery to the recipient. There is no significant delay in the message transfer unless CMTA 2 is off-line or unreachable for some reason. 2.3 Email exchange between the users on local area networks (LAN) behind the firewalls and between Advanced mail service systems is shown on Fig. 3. --------- ---------- ---------- ----------- ------- | | | Server | | Server | internet | Server | | | | MUA 1 |---| IMTA 1 |--FW--| CMTA 1 |----//-------| CMTA 2 |---| MUA | --------- ---------- ---------- ----------- ------- Fig.: 3 IMTA is similar to CMTA in it's functionality to simplify systems administration. The main difference is in level and details about the user's configuration, and which email messages are kept on either server. IMTA keeps user's outgoing email messages for long term storage, while CMTA keeps only outgoing messages until they are requested by the remote recipient or expiration time. User 1 sends and receives email through IMTA 1 (Intermediate MTA) only. User's configuration parameters are stored on IMTA 1. Configuration information related to acceptance of type and sources of email from the internet is passed along to CMTA 1 in regular exchange of updates between the servers. Scenario 1: User creates a message for somebody for the first time. The message is delivered by MUA 1 to IMTA 1 which passes it along to CMTA 1. His configuration indicates that he's willing to accept all email indefinitely from the addressee. That configuration is also given to CMTA 1 for future reference. Assuming that the user 2 is also using Advanced mail system, she will be notified that user 1 wants to deliver a message to her. She uses her MUA to indicate that she wants to keep a long term correspondence with the sender of the message and pickup the message from her local server CMTA 2 which in turn sends a pickup request to CMTA 1. The body of the message gets delivered to CMTA 2 and is available to user 2 with very short delay. All future correspondence will pass between the users without a delay since both CMTAs have that information in their database. Scenario 2: User 2 is accepting all email from anywhere. When CMTA 1 connects to remote MTA the message from user 1 will be delivered as it is standard today in the year 2003. 2.4 Large service providers (AOL, etc.) Email exchange between subscribers to large Internet services is similar to the above described protocol with the exception of transitional servers, CMTAs. Email envelope is passed between the parties on first time email exchange. The recepient is in control of the message and makes the decision based on the subject line or sender address. Additional tests may be performed on the message body after the recepient decided to accept the message but before the message is delivered to their file. The result of the test is delivered to both parties. 3.0 Handling Attachments It is possible that some attachments to email messages include harmful code which cause erasure of user's data, replicate and spread virus based on user's address book, install and run spyware, or a combination of the above. When a new virus is discovered and it's signature becomes known, CMTA type of servers could be put into defensive mode where the messages would not be delivered automaticaly but kept on the sending servers for pickup by the end users as described in 2.2. Since virii spread without need for the user to be present, many such attacks would be slowed down significantly and could prevent major disruptions on the Internet with this protocol. That is especialy true for first time connections. 4.0 Transition Considerations The above described system provides means for smooth transition from current to the advanced email system. Users already familiar with the current system will easily adapt to the new system. 5.0 Potential Problems The protocol depends heavily on servers being accessible online all the time. This is not a problem for most systems that are connected to the Internet over DSL or better lines. 6.0 Summary One of the positive side effects of using this protocol for email exchange is in limited amount of traffic between the servers when there is more than one recipient. Message is transfered between the servers upon recepient's request. =============== NOTES =============== ftp://ftp.ietf.org/ietf/1id-guidelines.txt http://www.ietf.org/shadow.html ftp://ftp.isi.edu/in-notes/rfc2852.txt Deliver By SMTP Service Extension SMTP client can request, when transmitting a message to the SMTP server, that the server deliver the message within a prescribed period of time. A client making such a request also specifies the message handling which is to occur if the message cannot be delivered within the specified time period: either the message is to be returned as undeliverable with no further processing, or a "delayed" delivery status notification (DSN) [6] is to be issued.