Internet DRAFT - draft-szego-wcor-imap
draft-szego-wcor-imap
Internet-Draft D. Szego
Standards Track david@mindslip.org
Document: draft-szego-wcor-imap-00.txt January 2006
Welcomed Correspondence Extensions to IMAP4
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" [STD1] 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.1. 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
2.2. New Correspondence Requests
3. Commands and Headers
3.1. Identification of a WC-Compliant Mail Client
3.2. The LISTNEWREQ Command
3.3. The LISTPENDREQ Command
3.4. The ALLOW Command
3.5. The BLOCK Command
3.6. The LISTALLOWED Command
3.7. The LISTBLOCKED Command
4. Handling Email
4.1. From WC-Compliant MTA's
4.2. From Non-WC-Compliant MTA's
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 WC/WCor for short) extension to IMAP.
"Welcomed Correspondence" is explained in detail in Internet-Draft
draft-szego-wcor-overview-00.txt [WCor-Overview]. This extension is
based on the standard IMAP "Client Commands - Experimental / Expansion"
described in RFC 3501 [RFC3501] section 6.5. Welcomed Correspondence
capabilities are identified by the WCOR keyword in the IMAP capabilities
list presented by a WC-Compliant IMAP server implementation.
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].
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
1.2. Parameters
The following parameters are referenced below:
<email@as.per.rfc822.tld> (or <email@as.per.rfc822.tld>),
<orig-msg-id>, <orig-server>
The <email@as.per.rfc822.tld> parameter specifies the sender's email
address, as specified in RFC 822 [RFC822] section 6, "Address
Specifications".
The <orig-msg-id> parameter specifies the ID of the initial contact
email sent from the sender in question to the recipient in question.
This is taken from the SMTP "Message-ID" header if the initial contact
email was sent from a non-WC-Compliant SMTP server. If sent from a
WC-Compliant SMTP server, the server would have added a WCor
Original-Message-ID (<orig-msg-id>) header to the email, which MUST be
used if present. In either case, this message ID MUST be used for all
further references to the initial contact message between sender and
recipient.
The <orig-server> parameter specifies the SMTP server from which the
sender had sent the initial contact email. If sent from a
non-WC-Compliant SMTP server, this is gleaned from the SMTP
"Return-Path" header. If sent from a WC-Compliant SMTP server, the
server would have added a WCor Original-Server (<orig-server>) header,
containing the FQDN of the sending server, which MUST be used instead.
In either case, this server ID MUST be used for all further references
to the accepted SMTP server of a senders email.
All commands take their parameters in a form matching RFC 3501
[RFC3501] section 2.2, "Commands and Responses".
2. WCOR Capability Extension Overview
The WCOR capability provides Welcomed Correspondence extensions to an
IMAP server by allowing the IMAP server and client to interact directly
with a user's Welcome, Unwelcome, and Pending lists. This extension
MUST only be available in the AUTHENTICATED state, in order to assure
manipulation of the proper users lists, 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
a WCor-compliant IMAP server MUST have one set of lists. A WC-compliant
IMAP 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.
2.1.1. Contents of the Welcome List
The Welcome list MUST contain only a sender's
<email@as.per.rfc822.tld>, <orig-server> and <orig-msg-id> information.
2.1.2. Contents of the Unwelcome List
The Unwelcome list MUST contain only a sender's
<email@as.per.rfc822.tld>, <orig-server> 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 MUST contain only a sender's
<email@as.per.rfc822.tld>, <orig-server> 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.
2.2. New Correspondence Requests
An email from a sender who is not present in either the Welcome,
Unwelcome, or Pending list is considered a "New Correspondent", and the
email considered an "Initial Contact Email". The new email MUST be put
in the recipient's Pending list and flagged as a "New Correspondence
Request". (See below, section 5.)
3. WCOR Commands
The WCOR capability is defined as follows:
WCOR capability
CAPABILITY tag:
WCOR
Arguments:
none
Added commands:
LISTNEWREQ LISTPENDREQ ALLOW BLOCK LISTALLOWED LISTBLOCKED
SENDUPDATE
Standard commands affected:
none
Commands vaild in states:
AUTHENTICATED
Specification reference:
This document, and Internet-Draft [WCor-Overview]
Announced states / possible differences:
OK, PREAUTH / no
WCOR capability indicates that the following commands MUST be
available:
LISTNEWREQ
List New Correspondence Requests
LISTPENDREQ
List pending Correspondence Requests. This MAY include New
Correspondence Requests
ALLOW
Add a sender to the user's Welcome list, allowing further mail
from this sender
BLOCK
Add a sender to the user's Unwelcome list, blocking further
mail from this sender
LISTALLOWED
List Welcome senders
LISTBLOCKED
List Unwelcome senders
These commands are described below.
3.1. Identification of a WC-Compliant Mail Client
Mail clients MUST identify themselves as WC-Compliant by issuing the
WCOR command in the AUTHENTICATED state.
The server MUST reply with a proper IMAP "OK" result if it is
offering Welcomed Correspondence capabilities.
Example:
C: abcd WCOR
S: abcd OK WCOR I'm talking to a WCOR-capable client
Failure of the WCOR command MUST result in a proper IMAP "BAD"
message. The text of the result SHOULD include a comment explaining why
the command failed.
Example:
C: abcd WCOR
S: abcd BAD Authenticate first
C: efgh WCOR
S: efgh BAD WCOR Can't access WC lists at this time
3.2. The LISTNEWREQ Command
The LISTNEWREQ command generates a list of "New Correspondence
Requests" from the WC-Compliant IMAP server, for the authenticated user.
Once presented in a New Correspondence Request list, a sender SHOULD
be un-marked as "New" within a reasonable time. This allows for a New
Correspondence Request to be left unanswered for an amount of time.
After this time, the WC-Compliant IMAP server SHOULD remove the sender's
"New" flag from the Pending list automatically, thus causing the sender
to be seen as a result of the LISTPENDREQ command rather than the
LISTNEWREQ command.
The LISTNEWREQ command does not take any parameters.
This command MUST reply with a proper IMAP "OK" result if there are
zero (0) or more entries in the user's Pending list marked as New
Correspondence Requests. The initial text of the result SHOULD include
a commant detailing the number of New Correspondence Requests.
Example:
C: a000 LISTNEWREQ
S: a000 OK There are no New Correspondence Requests at this time.
If there is one (1) or more entries in the user's Pending list marked
as New Correspondence Requests, the IMAP server MUST respond with each
entry on a separate line beginning with a "*" (asterix) tag. The list
MUST be terminated with a proper "OK" response on a final line by
itself. Blank lines MUST NOT appear between list entries.
The format for the response is as follows:
Name-if-given <email@as.per.rfc822.tld> <SP> <orig-server> <SP>
<Receipt-Date> <SP> Subject to end of line <EOL>
Example:
C: a001 LISTNEWREQ
S: * David Szego <dszego@mindslip.com> smtp.mindslip.com
11022004-213233 Re: Your question
S: * John Doe <jdoe@sender.net> mail.spam.com 12022004-094312 Buy
Pharmaceuticals Online!
S: * spam@spammer.com fake.spam.net 12022004-125326 E.n.l.a.r.g.e
yourself
S: a001 OK You have 3 New Correspondence Requests
Failure of the LISTNEWREQ command MUST result in a proper IMAP "BAD"
result. The text of the result SHOULD include a comment explaining why
the command failed.
Example:
C: a002 LISTNEWREQ
S: a002 BAD Cannot access WC lists at this time
3.3. The LISTPENDREQ Command
The LISTPENDREQ command generates a list of pending Correspondence
Requests from the user's Pending list. This SHOULD also include any
Pending requests marked as "New". Issuing this command MAY cause the
IMAP server to mark New Correspondence Requests as no longer new, but
this MUST NOT occur if the entries have not already been presented as a
result of the LISTNEWREQ command.
The LISTPENDREQ command does not take any parameters.
This command MUST reply with a proper IMAP "OK" result if there are
zero (0) or more entries in the user's Pending list. The initial text
of the result SHOULD include a comment detailing the number of Pending
Correspondence Requests.
Example:
C: aaaa LISTPENDREQ
S: aaaa OK There are no pending Correspondence Requests at this
time
If there is one (1) or more entries in the user's Pending list marked
as New Correspondence Requests, the IMAP server MUST respond with each
entry on a separate line before the "OK" reply. The list MUST be tagged
with a single "*" (asterix) beginning each line. Blank lines MUST NOT
appear between list entries.
The format for the response is as follows:
Name-if-given <email@as.per.rfc822.tld> <SP> <orig-server> <SP>
<Receipt-Date> <SP> Subject to end of line <EOL>
Example:
C: bbbb LISTPENDREQ
S: * David Szego <dszego@mindslip.com> smtp.mindslip.com
11022004-213233 Re: Your question
S: * John Doe <jdoe@sender.net> mail.spam.com 12022004-094312 Buy
Pharmaceuticals Online!
S: * spam@spammer.com asdf.fake.net 12022004-125326 E.n.l.a.r.g.e
yourself
S: bbbb OK You have 3 pending Correspondence Requests
Failure of the LISTPENDREQ command MUST result in a proper IMAP "BAD"
result. The text of the result SHOULD include a comment explaining why
the command failed.
Example:
C: cccc LISTPENDREQ
S: cccc BAD Cannot access WC lists at this time
3.4. The ALLOW Command
The ALLOW command tells the WC-Compliant IMAP server to add a sender
to a user's Welcome list, thus allowing (welcoming) further emails from
this sender.
The ALLOW command takes the following parameters:
<email@as.per.rfc822.tld> <SP> <orig-server> <SP> <orig-msg-id>
Example:
ALLOW dszego@mindslip.com smtp.sender.net
1234567.98765432@smtp.sender.net
Successful addition of this sender to a user's Welcome list MUST
result in a proper IMAP "OK" reply. The text of the result SHOULD
include a comment explaining that the sender has been added to the
user's Welcome list.
Example:
C: a000 ALLOW dszego@mindslip.com smtp.sender.net
1234567.98765432@smtp.sender.net
S: a000 OK dszego@mindslip.com is now allowed to send you email
Entire domains can be allowed by specifying the asterisk wildcard.
This is especially useful for intranets and corporate correspondence.
The entry will permanently sit in the "Pending" list, but will
automatically respond as an ALLOW to any incoming email address from the
specified domain, which isn't already in the Welcome list. The
orig-msg-id portion specifying a message ID MUST be a unique string
generated by the allowing server. The orig-msg-id portion specifying
the domain MUST match the domain being allowed (as opposed to the
particular sending server).
Example:
C: a001 ALLOW *@mindslip.com mindslip.com
1234567.09876543@mindslip.com
S: a001 OK The domain mindslip.com is now allowed to send you
email
Failure of the ALLOW command MUST result in a proper IMAP "BAD"
message. The text of the result SHOULD include a comment explaining why
the command failed.
Example:
C: a002 ALLOW dszego@mindslip.com smtp.sender.net
1234567.98765432@smtp.sender.net
S: a002 BAD Cannot access WC lists at this time
Addition of a user already present in the Welcome list MUST result in
success, in order to avoid needless parsing of error messages.
An ALLOW command MUST cause the IMAP server to check for the presence
of the sender's <email@as.per.rfc822.tld> / <orig-server> /
<orig-msg-id> in both the Pending and Unwelcome lists. If the sender
being allowed is present in either list, it must be removed from that
list in order to properly reflect the acceptance state of this sender.
Entries are not considered duplicate if they have the same email
address, but do not have the same <orig-server> and <orig-msg-id>
information. This allows senders to send from multiple SMTP servers.
Senders specified in an ALLOW command MUST be added if the command
parameters are valid, even if they have not been found in the other
lists. This is in order to use WC services as a full server-side
White/Blacklist server.
3.5. The BLOCK Command
The BLOCK command tells the WC-Compliant IMAP server to add a sender
to a user's Unwelcome list, thus blocking further emails from this
sender.
The BLOCK command takes the following parameters:
<email@as.per.rfc822.tld> <SP> <orig-server> (optional: <SP>
<orig-msg-id>)
Example:
BLOCK spammer@spam.net smtp.spamco.com
If no <orig-msg-id> is given, any message matching the specified
address and server is blocked. This parameter is optional, but MUST be
kept in the Unwelcome list if specified, in order to allow the user to
unblock the sender by moving the entry to the Welcome list.
Successful addition of this sender to a user's Unwelcome list MUST
result in a proper IMAP "OK" reply. The text of the result SHOULD
include a comment explaining that the sender has been added to the
user's Unwelcome list and blocked.
Example:
C: a000 BLOCK spammer@spam.net smtp.spamco.com
S: a000 OK spammer@spam.net is now blocked from sending you mail
from smtp.spamco.com
Failure of the BLOCK command MUST result in a proper IMAP "BAD"
reply. The text of the result SHOULD include a comment explaining why
the command failed.
Example:
C: a001 BLOCK spammer@spam.net smtp.spamco.com
S: a001 BAD Cannot access WC lists at this time
Addition of a user already present in the Unwelcome list MUST result
in success, in order to avoid needless parsing of error messages.
A BLOCK command MUST cause the IMAP server to check for the presence
of the sender's <email@as.per.rfc822.tld> / <orig-server> /
<orig-msg-id> in both the user's Pending and Welcome lists. If the
sender being blocked is present in either list, it must be removed from
that list in order to properly reflect the state of this sender. The
subject line (if not empty) MUST be copied from the Pending list to the
Blocked list.
Entries are not considered duplicate if they have the same email
address, but do not have the same <orig-server> information. This
allows duplicate email addresses to be blocked from multiple SMTP
servers.
Senders specified in a BLOCK command MUST be added if the command
parameters are valid, even if they have not been found in the other
lists. This is in order to use WC services as a full server-side
White/Blacklist server.
3.6. The LISTALLOWED Command
The LISTALLOWED command generates a user's list of Welcome senders
from the WC-Compliant IMAP server.
The LISTALLOWED command does not take any parameters.
This command MUST reply with a proper IMAP "OK" result if there are
zero(0) or more entries in the user's Welcome list. The initial text of
the result SHOULD include a comment detailing the number of Welcome
senders.
Example:
C: a002 LISTALLOWED
S: a002 OK There is nobody on your Welcome list
If there is one (1) or more entries in the Welcome list, the IMAP
server MUST with each entry on a separate line before the "OK" reply.
The list MUST be tagged with a single "*" (asterisk) prefixing each
line. Blank lines MUST NOT appear between list entries.
The format for the response is as follows:
Name-if-given <email@as.per.rfc822.tld> <SP> <orig-server> <SP>
<orig-msg-id><EOL>
Example:
C: a003 LISTALLOWED
S: * David Szego <dszego@mindslip.com> smtp.mindslip.com
12345654321abcd
S: a003 OK You have 1 people on your Welcome list
Failure of the LISTALLOWED command MUST result in a proper IMAP "BAD"
result. The text of the result SHOULD include a comment explaining why
the command failed.
Example:
C: a004 LISTALLOWED
S: a004 BAD Cannot access WC lists at this time
3.7. The LISTBLOCKED Command
The LISTBLOCKED command generates a user's list of Unwelcome senders
from the WC-Compliant IMAP server.
The LISTBLOCKED command does not take any parameters.
This command MUST reply with a proper IMAP "OK" result if there are
zero(0) or more entries in the user's Unwelcome list. The initial text
of the result SHOULD include a comment detailing the number of Unwelcome
senders.
Example:
C: a001 LISTBLOCKED
S: a001 OK There is nobody on your Unwelcome list
If there is one (1) or more entries in the Unwelcome list, the IMAP
server MUST with each entry on a separate line before the "OK" reply.
The list MUST be prefixed with a single "*" (asterisk) beginning each
line. Blank lines MUST NOT appear between list entries.
The format for the response is as follows:
Name-if-given <email@as.per.rfc822.tld> <SP> <orig-server> <SP>
<orig-msg-id> <SP> <Receipt-Date> <SP> Subject to end of line<EOL>
Example:
C: a002 LISTBLOCKED
S: Joe Spammer <spam@spammer.net> mail.spam.com 12345abcd
10.21.2003 E.n.l.a.r.g.e yourself
S: a002 OK You have 1 sender on your Unwelcome list
Failure of the LISTBLOCKED command MUST result in a proper IMAP "BAD"
result. The text of the result SHOULD include a comment explaining why
the command failed.
Example:
C: a003 LISTBLOCKED
S: a003 BAD Cannot access WC lists at this time
4. Handling Email
WC-Compliant IMAP servers will generally only need to specially
handle incoming email which has been delivered by a non-WC-Compliant
MTA. Email transferred through a WC-Compliant MTA will not get
delivered to the retreival (POP3/IMAP4/etc.) server in the first place.
Exceptions to this are initial-contact emails.
However, the IMAP server MUST be able to generate and handle "Control
Emails" (described below) in order to allow user's without a
WC-Compliant Mail Submission Agent (email program) to interact with
their Welcome / Unwelcome / Pending lists.
4.1. From WC-Compliant MTAs
If an email received by the IMAP server has the <orig-server> and
<orig-msg-id> headers ("WC Headers"), it can safely be assumed that the
email was delivered by a WC-Compliant MTA. These headers along with the
email address in the "From" header MUST be used to identify this sender
against the WC lists. The <orig-msg-id> header will be used to confirm
that this is indeed the original sender, as only the original sender's
MTA should know this ID.
If an email received by the IMAP4 server does not have the
<orig-server> and <orig-msg-id> headers, it can safely be assumed that
the email was delivered by a non-WC-Compliant MTA. In this case, the
<orig-server> value MUST be gleaned from the SMTP Return-Path headers,
and the <orig-msg-id> value MUST come from either the SMTP Message-ID,
or the SMTP In-Reply-To headers.
WC-Compliant IMAP servers MUST check all emails for the presence of
the WC Headers. If present, and if the IMAP software knows it is
running with a WC-Compliant MTA (for instance in a software suite), it
MAY be assumed that the WC-Compliant MTA would not have delivered the
email to the recipient's mailbox if it were Unwelcome. In this case,
the email MUST be checked against the recipient's Pending list. If the
WC Header values are present in the Pending list, it MAY be delivered
(optionally, as described above) or discarded.
4.2. From Non-WC-Compliant MTAs
Email from non-WC-Compliant MTAs will be missing the <orig-server>
and <orig-msg-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 Welcome / 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", and the WC Header values (as
gleaned), along with the subject line, and receipt date, MUST be added
to the recipient's Pending list, and marked as a New Correspondence
Request for presentation when the next LISTNEWREQ command is issued by
the recipient.
If the WC Header values (as gleaned) do match an entry, at MINIMUM
the email address and <orig-server> value, the email MUST be acted upon
according to which list it is present in, Welcome or Unwelcome. Emails
matching an entry in the user's Pending list SHOULD NOT be delivered, as
the sender SHOULD be considered temporarily blocked. This MAY be a
configurable option (to deliver email from a sender while in the Pending
state, or not) in the IMAP server implementation.
5. Handling Non-WC-Compliant Mail Clients: New Correspondence Requests
WC-Compliant mail clients MUST issue the WCOR command in the PREAUTH
state to identify themselves as WC-Compliant. If a mail client does not
issue the WCOR command, a WC-Compliant IMAP server MUST assume the
client is not WC-Compliant and handle New Correspondence Requests by
generating a "New Correspondence Requests Email".
If there is one (1) or more New Correspondence Requests, that is,
entries in a users Pending list which are flagged as New, the IMAP
server MUST generate a New Correspondence Requests Email, which MUST be
presented to the user as a new unread email, and delivered to the user
when the user retrieves their email. This is to allow non-WC-Compliant
email clients to interact with the WC-Compliant email server.
A New Correspondence Requests Email SHOULD look something like this:
From: WC-Mail-Server <dszego@mindslip.com>
Reply-To: dszego@mindslip.com
To: dszego@mindslip.com
Subject: New and Pending Correspondence Requests
Date: Friday, March 12th 2004
This is the mail server at pop-imap.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=WC<uid>-Allow">
[Block this sender]
<"mailto:dszego@mindslip.com?subject=WC<uid>-Block">
From: Joe Blow <jb@somewhere.com>
Subject: Meeting next thursday
[Allow this sender]
<"mailto:dszego@mindslip.com?subject=WC<uid>-Allow">
[Block this sender]
<"mailto:dszego@mindslip.com?subject=WC<uid>-Block">
From: Cain Able <cable@isp.tv>
Subject: Meet people in your area asdfjjsfe
[Allow this sender]
<"mailto:dszego@mindslip.com?subject=WC<uid>-Allow">
[Block this sender]
<"mailto:dszego@mindslip.com?subject=WC<uid>-Block">
Pending:
From: Al Phabet <abcde@xyz.com>
Subject: Urgent request for help
[Allow this sender]
<"mailto:dszego@mindslip.com?subject=WC<uid>-Allow">
[Block this sender]
<"mailto:dszego@mindslip.com?subject=WC<uid>-Block">
(Pending since 01/01/2004)
The format of the email SHOULD be similar in presentation to the
above example. It MUST allow at least the ability to act on New
Correspondence Requests (block or allow). It MAY provide the ability to
act on Pending requests, and SHOULD do so by presenting Pending requests
if the list of Pending senders is not too long to handle in such an
email.
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 in the subject (see example above).The IMAP 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 IMAP server
MUST keep track of it's generated UIDs in order to verify authenticity.
The IMAP server MUST NOT deliver the 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 IMAP server
MUST be able to intercept and interpret the users action reply emails.
Reply emails specifying an "Allow" command MUST act as if an ALLOW
command was issued in the TRANSACTION state by the user, on the sender
in question.
Reply emails specifying a "Block" command MUST act as if an BLOCK
command was issued in the TRANSACTION state by the user, on the sender
in question.
New Correspondence Requests not acted upon MAY be moved to the
Pending list as described in the LISTPENDREQ command section.
In this way, the IMAP server is able to present the user with a list
of 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 six (6) new IMAP commands and one (1) new
capability keyword as protocol extensions in compliance with RFC 3501
[RFC3501] section 6.5.
IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located at
<http://www.iana.org/assignments/imap4-capabilities> and in RFC
3501 [RFC3501].
IANA is requested to add these IMAP commands and capability keyword
to the registries.
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-01", June 2005
[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
