Internet DRAFT - draft-szego-wcor-smtp
draft-szego-wcor-smtp
Internet-Draft D. Szego
Standards Track david@mindslip.org
Document: draft-szego-wcor-smtp-00.txt June 2005
Welcomed Correspondence Extensions to ESMTP
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. Terminology
1.2. Parameters
2. WCOR Service Extension Overview
2.1. WC Lists
2.1.1. Contents of the Welcome List
2.1.2. Contents of the Unwelcome List
2.1.3. Contents of the Pending List
3. Commands and Headers
3.1. X-WCOR Command
3.2. X-Orig-Server Header
3.3. X-Orig-Msg-ID Header
4. Handling Email
4.1. From Non-WC-Compliant Mail Transfer Agents
4.2. From WC-Compliant Mail Transfer Agents
5. Handling Non-WC-Compliant Mail Clients:
"New Correspondence Requests"
6. IANA Registry Considerations
7. Security Considerations
8. Full Copyright Statement
9. References
10. Author's Address
1. Abstract
This document describes in detail the WCOR ("Welcomed
Correspondence", or WCor/WC for short) extension to ESMTP.
"Welcomed Correspondence" is explained in detail in Internet-Draft
draft-szego-wcor-overview-00.txt [WCor-Overview]. This extension is
based on the standard SMTP "Service Extensions" described in RFC 1869
[RFC1869]. ESMTP extensions themselves are not formally described here.
Welcomed Correspondence capabilities are identified by the X-WCOR (while
this document is in draft state) and eventually the WCOR keyword (when
and if accepted to standards state) in the ESMTP commands list presented
by a compliant ESMTP server implementation in response to an EHLO
greeting.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", and "MAY" in this document are to be interpreted as
defined in BCP 14, RFC 2119 [KEYWORDS].
All syntax described in this document follows the syntax conventions
of RFC 1738 [RFC1738].
1.2. Parameters
The following parameters are referenced below:
<email> <orig-msg-ID> <orig-srv>
The "<email>" parameter specifies the sender's email address, as
specified in RFC 822 [RFC822] section 6, "Address Specifications".
The "<orig-msg-ID>" and "<orig-srv>" parameters specify the Original
Message ID and Original Server as described in section 2. below.
All commands take their parameters in a form matching RFC 2449
[RFC2449] section 3, "General Command and Response Grammar".
2. WCOR Service Extension Overview:
The X-WCOR service extension provides Welcomed Correspondence
extensions to an ESMTP server by allowing the ESMTP server and client to
interact directly with a mail recipient's Welcomed, Unwelcome, and
Pending lists. It is STRONGLY RECOMMENDED that this extension be used in
conjunction with authenticated ESMTP connections in order to assure mail
is being sent from a legitimate user of the originating ESMTP server,
that is, the currently authenticated user.
2.1. WC Lists
WC Lists are white and black lists (and an "unspecified" list) of
Welcomed and Unwelcome and Pending email senders. Each valid account on
an ESMTP server MUST have one set of lists. A WC-compliant ESMTP server
MUST be able to interact with these lists, either directly or
indirectly. Actual interaction methods (database, etc.) are not
specified in this document and are left up to the implementation. It is
RECOMMENDED that any system which implements a unified
ESMTP/POP3/IMAP4/Email client suite uses a consistant method of
interacting with only a single set of lists.
See Internet-Draft [WCor-Overview] for further details on WC Lists.
2.1.1. Contents of the Welcome List
The Welcomed list contains only a sender's <email>, <orig-srv> and
<orig-msg-ID> information.
2.1.2. Contents of the Unwelcome List
The Unwelcome list contains a sender's <email>, <orig-srv> and
<orig-msg-ID> information, the date of receipt of the initial email, and
the subject line of the initial contact email.
2.1.3. Contents of the Pending List
The Pending list contains a sender's <email>, <orig-srv> and
<orig-msg-ID> information, the date of receipt of the initial email, and
the subject line of the initial contact email. Each entry can be flagged
as a "New Correspondence Request", if it is within a certain age.
3. Commands and Headers
The X-WCOR / WCOR service extension is defined as per RFC 1869
[RFC1869] as follows:
Command name:
X-WCOR
Arguments:
none
Added parameters:
none, only header data
Standard commands affected:
none, only header data
Additional email headers:
X-Orig-Msg-ID, X-Orig-Server
Specification reference:
This document, and Internet-Draft [WCor-Overview]
X-WCOR service extension adds the following email headers:
X-Orig-Server
X-Orig-Msg-ID
3.1. X-WCOR Command
The X-WCOR command is issued in order to alert the ESMTP server that
it is speaking with a WC-compliant MSA (Mail Submission Agent). It MUST
be preceeded by an EHLO command, and MUST only be issued in response to
the presence of the X-WCOR (or WCOR) keyword in the resulting list of
ESMTP service extensions. Issuing this command will enable the ESMTP
servers to distinguish between welcomed and unwelcome email before
transferring the body of the email to the recipient.
Mail Submission Agents MUST identify themselves as WC-compliant by
issuing the EHLO greeting followed by the X-WCOR or WCOR command if
offered by the server.
The server MUST reply with a proper SMTP "OK" result if it is
offering Welcomed Correspondence capabilities.
Example:
S: 220 smtp.sender.net ESMTP Daemon
C: EHLO example.com
S: 250-smtp.sender.net Hello example.com
250-SIZE 10485760
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250-X-WCOR
250 HELP
C: X-WCOR
S: 250 I'm talking to a WCOR-capable client
Failure of the X-WCOR / WCOR command MUST result in a proper SMTP
error message. The text of the result SHOULD include a comment
explaining why the command failed.
Example:
S: 220 smtp.sender.net ESMTP Daemon
C: EHLO example.com
S: 250-smtp.sender.net Hello example.com
250-SIZE 10485760
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250-X-WCOR
250 HELP
C: X-WCOR
S: 450 Can't access WC lists at this time
3.2. X-Orig-Server Header
Originating Server. This header is automatically added as a header to
a new message by the originating ESMTP server, and passed on intact in
transport to the destination SMTP server.
The X-Orig-Server header specifies the SMTP server from which the
sender had sent the initial contact email (See RFC/Draft XXX, "Welcomed
Correspondence Overview"). The content of this header is the fully
qualified domain name of the originating ESMTP server (i.e.
"mail.sender.net"). If a message is being submitted without this header
(as would be the case if sent from a non-WC-compliant MSA or MTA), this
content MUST be gleaned from the SMTP "Return-Path" header (if supplied)
or the FQDN of the sender, and an X-Orig-Sender header MUST be added by
the server on the client's behalf before further action. Thus, the
WC-compliant ESMTP server MUST act in a WC-compliant way even if the
X-WCOR command has not been issued. The content of this header MUST be
used for all further references to the accepted SMTP server of a senders
email.
3.3. X-Orig-Msg-ID Header
Original Message ID. This header specifies the ID of the initial
contact email sent from this sender to the recipient in question. Where
multiple recipients are specified, multiple X-Orig-Msg-ID headers MUST
be added, one for each recipient as applicable. Where no X-Orig-Msg-ID
header is supplied (as would be the case if sent from a non-WC-compliant
MSA or MTA), this header MUST be added by the server on the client's
behalf before further action. Thus, the WC-compliant ESMTP server MUST
act in a WC-compliant way even if the X-WCOR command has not been
issued.
The content of this header MUST be a unique ID. This MAY taken from
the SMTP "Message-ID" or "In-Reply-To" headers if no X-Orig-Msg-ID
header is supplied, or if the initial contact email was sent from a
non-WC-compliant SMTP server.
See below (x.x Handling Email and x.x New Correspondence Requests)
for further details on when and how to add these headers.
4. Handling Email
If the server is not the final destination for an email (i.e. a
transitory upstream MTA from the sender), the server MUST pass on any
WCOR headers intact.
If, however, the server is the final destination for an email (i.e.
the recipient's account is on this server), the WC-compliant ESMTP
server will have to handle email sent from both WC-compliant and
non-WC-compliant MSAs. These two situations will have to be handled
differently in order to determine if the sender is allowed to send to
this recipient (Welcomed), if the sender is not allowed (Unwelcome), or
if this sender is as-yet unknown to the recipient. The lattermost case
will trigger a "New Correspondence Request".
The WC-compliant ESMTP server MUST also be able to generate and
handle "Control Emails" (described below) in order to allow users
without a WC-compliant Mail Submission Agent (email program) to interact
with their Welcomed / Unwelcome / Pending lists.
4.1. From WC-Compliant MTAs
If an email received by the final-destination WC-compliant ESMTP
server has the "X-Orig-Server" and "X-Orig-Msg-ID" headers, it can
safely be assumed that the email was sent by a WC-compliant MSA or
originating MTA. These headers along with the email address in the
"From" header MUST be used to identify this sender against the
recipient's WC lists. The "X-Orig-Msg-ID" header MUST be used to confirm
that this is indeed the original sender, as only the original sender's
MTA or MSA should know this ID.
If an email received by the final-destination WC-compliant ESMTP
server does not have the "X-Orig-Server" and "X-Orig-Msg-ID" headers, it
can safely be assumed that the email was delivered by a non-WC-compliant
MTA and submitted by a non-WC-compliant MSA. In this case, the
"X-Orig-Server" value MUST be gleaned from the SMTP Return-Path headers,
and the "X-Orig-Msg-ID" value MUST come from either the SMTP Message-ID,
or the SMTP In-Reply-To headers (see sections 2.3 and 2.4 above).
Once the X-Orig-Msg-ID and X-Orig-Server header data is obtained, the
WC-compliant ESMTP server MUST check the recipient's WC Lists for an
entry matching this sender.
If the headers match an entry in the recipient's Welcomed list, the
email SHOULD be delivered without further intervention, assuming all
other transaction details are valid.
If the data set matches an entry in the recipient's Unwelcome list,
the server MUST reply with an error code stating the sender has been
blocked from this recipient.
Example:
C: X-WCOR
S: 250 I'm talking to a WCOR-capable client
C: MAIL FROM: sender@originator.com
S: 250 ok
C: RCPT TO: recipient@destination.net
S: 250 ok
C: DATA
S: 354 send the mail data, end with .
C: Date: 23 Oct 81 11:22:33
C: From: SMTP@HOSTY.ARPA
C: To: JOE@HOSTW.ARPA
C: X-Original-Server: smtp.originator.com
C: X-Msg-ID: UUID103a93c5e89f2bb823ad
C: Subject: This isn't spam!
C:
C: Hi! I'd like to sell you something!
C: .
S: 553 Recipient has blocked this sender
Error code 553 is RECOMMENDED. The error SHOULD explain that a sender
has been blocked.
If the headers match an entry in the recipient's Pending list, the
server MAY reply with a temporary error code (4xx series) stating the
recipient has not yet accepted email from this sender. This is not a
permanent error (5xx series) because the sender has not yet been
formally blocked. Error code 453 is RECOMMENDED, and SHOULD explain that
the sender is pending approval of contact from the recipient.
Optionally, the email transaction MAY go through, assuming all other
transaction details are valid, and the email MAY be delivered, or
discarded without notification to the sender.
These options are dependent on the specific ESMTP / WCOR
implementation, and MAY be configurable either by the ESMTP
administrator, or on a per-user basis (see RFC/Draft XXX, "Welcomed
Correspondence Overview", section X).
If no entry can be matched in any WC List, the email must be
considered an "Initial Contact Email". See section 4.3 below.
4.2. From Non-WC-Compliant MTAs
Email from non-WC-compliant MTAs will be missing the
"X-WC-Original-Server" and "X-WC-Original-Message-ID" headers as
described above. If an email is missing these WC Headers, their
equivalent content MUST be gleaned as described above and added to the
message. The gleaned WC headers MUST then be checked against the
recipient's Welcomed / Unwelcome / Pending lists to determine whether
the email should be delivered.
If the WC header values do not match an entry, the email MUST be
considered an "Initial Contact Email". See section 4.3 below.
If the WC header values (as gleaned) do match an entry (at MINIMUM
the <email> address and gleaned <orig-srv> value), the email MUST be
acted upon according to which list it is present in, Welcomed or
Unwelcome.
Emails matching an entry in the user's Pending list MAY be delivered
or discarded as described above.
5. Handling Non-WC-Compliant Mail Clients: "New Correspondence Requests"
An email from a sender who is not present in either the recipients
Welcomed, Unwelcome, or Pending list is considered a "New
Correspondent", and the email considered an "Initial Contact Email". The
details of the email are be put in the recipient's Pending list (see
section 3.3, "Contents of the Pending List", above) and flagged as a
"New Correspondence Request".
See also RFC/Draft XXXX, "Welcomed Correspondence Overview" for
further details on New Correspondence Requests.
Requests are acted upon by providing a mailto: URL in the email which
specifies the user themselves as the recipient, and a unique ID and
action (block or allow) in the subject.
A WCor-compliant SMTP server MUST intercept any emails it sees from
the user to themselves, with the server's own generated UID in the
subject line. Thus, the SMTP server MUST keep track of it's generated
UIDs in order to verify authenticity. The SMTP server MUST NOT deliver
these action replies to the user after intercepting. It MAY generate and
deliver an email with confirmation of actions taken.
Regardless of the scope of abilities presented to non-WC-compliant
mail clients in the "New Correspondence Requests Email", the SMTP server
MUST be able to intercept and interpret the users action reply emails.
Reply emails specifying an "Allow" command MUST act as if a
WCor-IMAP/POP ALLOW command was issued in the TRANSACTION state by the
user, on the sender in question [Draft-XXX].
Reply emails specifying a "Block" command MUST act as if a
WCor-IMAP/POP BLOCK command was issued in the TRANSACTION state by the
user, on the sender in question [Draft-XXX].
New Correspondence Requests not acted upon MAY be moved to the
Pending list as described in the WCor-IMAP/POP LISTPENDREQ command
section [Draft-XXX].
In this way, the SMTP server is able to act on the recipient's
replies to New Correspondence Requests when the user is not using
WC-compliant email client, and act upon the users choices by using a
mechanism similar to mailing-list control emails.
6. IANA Registry Considerations
This document specifies one (1) new ESMTP command and two (2) new SMTP
headers as protocol extensions in compliance with RFC 2821 [RFC2821]
section 8.
IANA is requested to add these (E)SMTP commands and headers keyword
to the registry.
7. Security Considerations
Welcomed Correspondence extensions rely on authenticated connections
to existing email services. These are provided for in current
RFC-standards for IMAP, POP, and SMTP, and are available in most modern
server and client implementations. The WCor suite of protocol extensions
insists that authentication MUST be used in order to verify use and
alteration of WCor lists.
Orig-msg-id strings are sent in the clear, and as such are susceptible
to man-in-the-middle attacks. As this is not a security-critical
protocol extension, this is not a significant concern, however it is
RECOMMENDED that SSL encryption is used on all email server connections
as a general security best-practice. This would also negate the concern
of interception of orig-msg-id strings, used to authenticate list
manipulation requests.
8. 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.
9. References
[STD1] Postel, J., "Internet Official Protocol Standards", STD 1, RFC
1540, Internet Architecture Board, October 1993.
[BCP79] S. Bradner, "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, Intellectual Property Rights Working
Group of the IETF, February 2004
[WCor-Overview] D. Szego, "Welcomed Correspondence Overview",
Internet Draft "draft-szego-wcor-overview-00.txt", January 2006
[RFC3501] M. Crispin, "Internet Message Access Protocol, Ver. 4 Rev.
1", RFC 3501, March 2003
[KEYWORDS] S. Bradner, "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC1738] T. Berners-Lee, "Uniform Resource Locators (URL)", RFC
1738, December 1994
[RFC822] D. Crocker, "Standard for the Format of ARPA Internet Text
Messages", RFC 822, August 1982
10. Author's Address
David J. Szego
26 Valleyview Road
Thornhill, Ontario
L3T 6X5 Canada
david@mindslip.org
