Internet DRAFT - draft-szego-wcor-overview
draft-szego-wcor-overview
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 <dszego@mindslip.com>
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]
<mailto:dszego@mindslip.com?subject=<someuid>Allow>
[Block this sender]
<mailto:dszego@mindslip.com?subject=<someuid>Block>
From: Joe Blow, joe.blow@yahoo.com
Subject: Re: Meeting next thursday
[Allow this sender]
<mailto:dszego@mindslip.com?subject=<someuid>Allow>
[Block this sender]
<mailto:dszego@mindslip.com?subject=<someuid>Block>
From: Cain Able, cable@isp.net
Subject: Meet people in your area adsf87sda
[Allow this sender]
<mailto:dszego@mindslip.com?subject=<someuid>Allow>
[Block this sender]
<mailto:dszego@mindslip.com?subject=<someuid>Block>
Pending:
From: Al Phabet, abcde@xyz.com
Subject: Urgent request for help
[Allow this sender]
<mailto:dszego@mindslip.com?subject=<someuid>Allow>
[Block this sender]
<mailto:dszego@mindslip.com?subject=<someuid>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 "<orig-server>" 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 "<orig-msg-id>". 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
<orig-server> 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
<orig-server>, subject line, and <orig-msg-id>.
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 <orig-msg-id> (if present) is compared
against the <orig-msg-id> 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 <orig-server> or
Reply-Path header), along with the <orig-msg-id> (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 <orig-msg-id> 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 <orig-msg-id> 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 <orig-msg-id>). 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 <orig-server> fields matching the users old email
address and <orig-msg-id>. A new <orig-msg-id> 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
