Internet-Draft D. Szego Standards Track david@mindslip.org Document: draft-szego-wcor-overview-00.txt January 2006 Overview of Welcomed Correspondence Extensions to Mail Delivery and Mail Transfer Protocols Network Working Group Internet-Draft Submission Category: Standards Track Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. A revised version of this draft document will be submitted to the RFC editor as a Standard Track RFC for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to david@mindslip.org . Distribution of this memo is unlimited. Copyright (C) The Internet Society (2006). All Rights Reserved. Table Of Contents 1. Abstract 1.1 Phase I 1.2 Phase II 1.3 Moving to a New Server/Service 2. Full Copyright Statement 3. References 4. Author's Address 1. Abstract The goal of Welcomed Correspondence Extensions is to provide, in the simplest and least intrusive way possible (both programmatically and to the user), a method of avoiding unsolicited and unwanted email without drastically changing the infrastructure of the Internet's existing mail transports. This document describes a two-phase evolutionary approach in order to maintain compatibility with existing standard POP3/IMAP4 retrieval/delivery servers, SMTP mail transfer agents, and end-user mail clients. 1.1 Phase I Phase I allows Welcomed Correspondence Extensions functionality over standard SMTP mail transfer agents. This entails a somewhat basic addition of white/blacklist functions by adding "Welcome" "Unwelcome" and "Pending" lists to mail retrieval and delivery servers. These can be POP, IMAP, or other non-standard protocols which interact with SMTP and choose to implement Welcomed Correspondence Extensions. These Welcome, Unwelcome and Pending lists are maintained on the users mail delivery server in order to avoid duplication of "Junk Sender" and blacklists across multiple mail clients. This avoids client synchronization problems and frustrations to the user, and allows migration of users to new mail servers/services by synching lists between old and new servers and alerting Welcome senders. Note that all mail clients and delivery servers (POP/IMAP, etc) which support any WC-Extensions must support WC-II (Welcomed Correspondence Extensions, Phase II) but will operate in WC-I (Welcomed Correspondence Extensions, Phase-I) mode when interacting with non-WC-compliant mail transfer agents or mail clients. With a Welcomed Correspondence Phase I (WC-I) implementation, new "Correspondence Requests" are generated upon receipt of an email from an address not present in either the recipient's Welcome, Unwelcome, or Pending lists. This request MUST be presented to the user in either an email, or a "New Correspondents" list, depending on whether or not the email client identifies itself as WC-I compatible. Users have the choice of allowing or blocking email from the sender, or leaving a request unanswered in which case the email in question MAY be delivered for review, but further emails from this sender MUST NOT be delivered until the sender is added to the Welcome list. If, upon login to a WC-I compatible delivery server, a client does not identify itself as WC-I compatible, an email MUST be generated by the delivery server listing new and pending requests and providing internal reply-to addresses for each of the three possible actions (Allow, Block, or Leave Pending). The user MAY reply using the given mail-to link for each choice, sending an email to themselves which MUST BE intercepted by the WC-I retrieval server directly, and acted upon. This is analogous to controlling Mailing List subscriptions by mail commands sent to the mailing list server. From: WC-I-Server Reply-To: dszego@mindslip.com To: dszego@mindslip.com Subject: New and Pending Correspondence Requests Date: Fri, 16 Jan 2004 17:02:08 -0500 This is the mail server at pop3.incoming.com You have 3 new, and 1 pending Correspondence Requests: New: From: John Doe, jdoe@sender.net Subject: Buy pharmaceuticals online! [Allow this sender] Allow> [Block this sender] Block> From: Joe Blow, joe.blow@yahoo.com Subject: Re: Meeting next thursday [Allow this sender] Allow> [Block this sender] Block> From: Cain Able, cable@isp.net Subject: Meet people in your area adsf87sda [Allow this sender] Allow> [Block this sender] Block> Pending: From: Al Phabet, abcde@xyz.com Subject: Urgent request for help [Allow this sender] Allow> [Block this sender] Block> Pending since 01/01/2004 If a client identifies itself to the server as WC-I compatible, a "New Correspondents" list will be sent to the client for presentation in a manner applicable to the look and feel of the client interface/OS. The user may select an action for each request, which is communicated directly to the WC-I delivery server by the WC-I client. +------------------------------------------+ |[] New and Pending Correspondents - + X | |------------------------------------------| |+- New ----------------------------------+| || John Doe jdoe@sender.net +-------+ || || Buy pharmeceuticals online! | Allow | || || +-------+ || || +-------+ || || | Block | || || +-------+ || |+----------------------------------------+| |+- Pending ------------------------------+| || Al Phabet abcde@xyz.com +-------+ || || Urgent request for help! | Allow | || || +-------+ || || +-------+ || || | Block | || || +-------+ || |+----------------------------------------+| | +--------+ +----+ | | | Cancel | | OK | | | +--------+ +----+ | +------------------------------------------+ When a user decides on an action for a Correspondence Request, the WC-I compatible server adds the sender's email address and originating server (taken from the SMTP Return-Path header) to the users Welcome or Unwelcome list as appropriate. The entry MUST be removed from the Pending list if this was a previously pending sender. Incoming emails whose sender/server match an existing Welcome or Unwelcome entry MUST be delivered or withheld as appropriate. Emails whose sender/server matches a Pending entry MUST be temporarily treated as Unwelcome, and the Pending entry MUST remain in the user's New Correspondents list until acted upon. The senders address will not be duplicated in the New Correspondents list unless the address is seen coming from a new server, in which case it will be treated as a new entry. Pending lists MUST also contain the subject line of the initial contact email, as a reminder to the recipient when browsing long-standing Pending requests. Notification of additions to a users Unwelcome list MUST NOT be generated, to avoid confirmation of the recipient's existence to spam servers which may flood the recipient with future emails from bogus addresses, thus filling the New Correspondents list with bogus entries. +---+ New Email: | | To: recipient@incoming.com +---+ From: sender@outgoing.net | | 1 +-------+ \|/ +->|Welcome|<---+ +---------------------+ +---------------------+ | +-------+ | |Outgoing MTA (non-WC)| 2 |Incoming MTA (non-WC)| | +---------+ | | smtp.outgoing.net |->--->| smtp.incoming.com | +->|Unwelcome|<-+9 +---------------------+ ^ +---------------------+ 4| +---------+ | | | | 8| +-------+ | | | 3 | 7a +->|Pending|->--+ | \|/ \|/ | +-------+ | +---------------------+ | | |Incoming mail (WC-II)|->+ | | imap.incoming.com | | +---------------------+ 6a | | | ^ | | 5a | 5b | 6b | \|/ \|/ | +----------------------+ +----------------------+ |Email client (non-WC) | | Email client (WC-II) | |recipient@incoming.com| |recipient@incoming.com| +----------------------+ +----------------------+ Figure 2: Welcomed Correspondence Phase I 1.2 Phase II Phase II extends Welcomed Correspondence white/blacklist functions to the SMTP Mail Transfer servers, allowing for a more automated method of confirming whether a sender is welcome or not, with less user interaction. This is done by allowing interaction between the SMTP server (or mail gateway), and the Welcomed/Unwelcome/Pending lists directly. When sending an email to a new recipient, a WC-II compatible SMTP server adds an "" header to the email, and adds the recipient's address to both the senders Welcome and Pending lists, as well as adding the email's SMTP Message ID to the senders Pending list as an "". This is done to indicate that a reply email from this recipient would be welcomed, as the sender has initiated contact, thus removing the need for further intervention by the sender. The receiving mail gateway, if WC-II compatible, then looks for the sender's address and originating server in the recipient's lists (either from the header if present or from the SMTP Reply-Path header). If the combination is found in either the Welcome or Unwelcome list, the server acts appropriately. If the sender's email address is not found, it is added to the recipient's Pending list, along with the , subject line, and . If further emails are sent to a recipient who is present in the sender's Pending and Welcome list, it is assumed that the email will not yet be accepted by the recipient and the mail transfer agent MUST NOT accept submission of the email for delivery. An appropriate bounce notification SHOULD be sent by the mail transfer agent to the sender stating that the sender has not yet been welcomed by that particular recipient. This avoids confirmation of the recipient's existence, protection against spam flooding and multiple unwanted requests, and inefficient use of bandwidth between mail transfer agents. If, upon receipt of an email, the e-mail/sender/server combination is found in both the recipient's Pending and Welcome lists, the SMTP-In-Reply-To header or (if present) is compared against the held in the recipient's Pending list. If this matches, confirming that the sender is replying to a message originating from the recipient, the sender/server (from the or Reply-Path header), along with the (if present) or SMTP-Message-ID is added to the recipient's Welcome list and is removed from the Pending list automatically. If the sender/server combination is found in both the recipient's Pending and Welcome lists, but the header is not present or does not match and the SMTP In-Reply-To header does not match (as would happen in the case of an initial email from a WC-II MTA to a WC-I MTA, and a reply from the WC-I MTA back to the WC-II MTA), a Reply-Confirmation-Request is presented to the recipient, in a format appropriate for the interface of the mail client, to allow the recipient to confirm that this is a message from a sender the recipient has at some point sent a message to. If confirmed, the sender is added to the recipient's Welcomed list and removed from their Pending list. If this can't be confirmed, the sender is considered a New Correspondent, and the recipient is presented with a choice of actions, Allow/Block/Hold Pending. If a New Correspondent is welcomed by a WC-II compliant recipient, and the sender's email contains an header, (indicating the sender is using a WC-II compliant server) an Acceptance reply is sent to the sender's Originating-Server indicating that the sender (identified by the sender's email address) has been accepted into the recipient's Welcome list (indicated by the recipient's email address and confirmed by the sender's ). This is done automatically (and silently) by the welcoming recipient's WC-II compliant mail client, thus automating the acceptance process and alerting the sender that they are a Welcomed Correspondent. If this is not done automatically or sent successfully, the sender is unable to send further messages, even though the recipient has welcomed them, until the recipient replies, thus triggering the sender's delivery server to match the recipient's sender/server addresses and move them from the Pending list to the Welcomed list. WC-II compliant mail delivery servers MUST process bounce messages from unsuccessful acknowledgements by re-sending the Acceptance messages or alerting the user. +---+ New Email: | | To: recipient@in.com +---+ From: sender@out.net | | 1 Msg-id: 1234567 \|/ Originating Server: +--------------------+ smtp.out.net 3 +--------------------+ |Outgoing MTA (WC-II)|->----------------->|Incoming MTA (WC-II)| | smtp.out.net |<-----------------<-| smtp.in.com |->--+ +--------------------+ Accepted 10 +--------------------+ | | | In-Reply-To: 1234567 | 5 | | | Originating Server: | | | 11 | smtp.in.com \|/ | | | Reply-To: +-------------------------+ | 4 | | recipient@in.com |Incoming delivery (WC-II)| | | 2 | Originating Server: | pop-imap.in.com |->+ | | | smtp.in.com +-------------------------+ | | | | orig-msg-id: 1234567 | ^ | | | | | 6 | 7 | | | \|/ | | 8 | | | +-------+ \|/ | | | +-->|Welcome| +----------------------+ | | | +-------+ | Email client (WC-II) | | | | +---------+ |recipient@in.com| | | | +-->|Unwelcome| +----------------------+ | | | +---------+ | | | +-------+ +-------+ | | +-->|Pending|-------> (Trash) |Welcome|<----+ | +-------+ 12 +-------+ | | +---------+ | | |Unwelcome|<-+| | +---------+ | +-------+ | (Trash)<--<-|Pending|<------+ +-------+ From: sender@out.net orig-msg-id: 1234567 Originating server: smtp.out.net Figure 3: Welcomed Correspondence Phase II In order to maintain Welcome and Unwelcome lists, WC-I and WC-II delivery servers MUST provide a list of Welcome and Unwelcome users. This is presented in either a WC-I compatible email as described above, or in a format applicable to the WC-II client's interface. It is RECOMMENDED that Unwelcome lists contain the subject line of the initial email from the unwelcome sender, as a reminder to the recipient. Pending lists MUST provide this. 1.3 Moving to a New Server/Service When a user changes email addresses, presumably the server name will change as well. This could forseeably result in all previously welcome senders having to re-request permission to send. By migrating Welcome/Unwelcome/Pending lists between old and new servers, and alerting existing welcome senders from the new address, the email addressee is able to keep their white/blacklists up to date with a simple one-time operation. A WC-II compliant email client can issue a request to list all welcome and unwelcome senders from the old service, add them to the lists on the new service, and then issue an update to these newly added senders. The update will alter the Welcome lists of the senders by changing the email address and fields matching the users old email address and . A new will be put in place of the existing, using a server-generated string. 2. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3. References [BCP79] S. Bradner, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, Intellectual Property Rights Working Group of the IETF, February 2004 [WCor-POP] D. Szego, "Welcomed Correspondence Extensions to IMAP4", Internet Draft "draft-szego-wcor-imap-00.txt", January 2006 [WCor-IMAP] D. Szego, "Welcomed Correspondence Extensions to POP3", Internet Draft "draft-szego-wcor-imap-00.txt", January 2006 [WCor-ESMTP] D. Szego, "Welcomed Correspondence Extensions to ESMTP", Internet Draft "draft-szego-wcor-imap-00.txt", January 2006 4. Author's Address David J. Szego 26 Valleyview Road Thornhill, Ontario L3T 6X5 Canada david@mindslip.org