[exim-dev] New Anti-Spam RFC Drafts: Welcomed Correspondence…

Good day,

I present to you a set of anti-spam measures called "Welcomed
Correspondence Extensions" comprising a set of extensions to SMTP/POP/
IMAP servers and email clients, as a new and novel approach to white
and black lists in the fight against unsolicited email. These have
recently been submitted to the IETF as standards-track Internet-Drafts.

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
(spam) without drastically changing the infrastructure of the
Internet's existing mail transports. These documents 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.

The attached documents are as follows:

draft-szego-wcor-overview-01.txt
A summary of Welcomed Correspondence (WCor) purpose and concepts

draft-szego-wcor-smtp-01.txt
Welcomed Correspondence Extensions to ESMTP Mail Transport Servers

draft-szego-wcor-imap-01.txt
Welcomed Correspondence Extensions to IMAP4 Mail Delivery Servers

draft-szego-wcor-pop-01.txt
Welcomed Correspondence Extensions to POP3 Mail Delivery Servers

A discussion forum, FAQ page, and copy of the drafts have been set up
at http://www.mindslip.org .

I look forward to your comments on these papers, and hope to have
your participation in seeing them through to fruition as accepted
extensions to mail protocols, and their implementation in popular
mail software.

Yours,
David J. Szego
david@???


Internet-Draft D. Szego

Standards Track                         david@???
Document: draft-szego-wcor-imap-01.txt  January 2006

        Welcomed Correspondence Extensions
                to IMAP4
Network Working Group 
Internet-Draft SubmissionCategory: 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, the 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 [BCP79]. 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@??? .
Distribution of this memo is unlimited.

Copyright (C) The Internet Society. 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-01.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@???> (or <email@???>),  <orig-msg-id>,  <orig-server>

The <email@???> 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@???>, <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@???>, <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@???>, <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@???> <SP> <orig-server> <SP> <Receipt-Date> <SP> Subject to end of line <EOL>

   Example:
      C: a001 LISTNEWREQ
      S: * David Szego <dszego@???> smtp.mindslip.com 11022004-213233 Re: Your question
      S: * John Doe <jdoe@???> mail.spam.com 12022004-094312 Buy Pharmaceuticals Online!
      S: * spam@??? 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@???> <SP> <orig-server> <SP> <Receipt-Date> <SP> Subject to end of line <EOL>

   Example:
      C: bbbb LISTPENDREQ
      S: * David Szego <dszego@???> smtp.mindslip.com 11022004-213233 Re: Your question
      S: * John Doe <jdoe@???> mail.spam.com 12022004-094312 Buy Pharmaceuticals Online!
      S: * spam@??? 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@???> <SP> <orig-server> <SP> <orig-msg-id>

   Example:
      ALLOW dszego@??? smtp.sender.net 1234567.98765432@???

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@??? smtp.sender.net 1234567.98765432@???
      S: a000 OK dszego@??? 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@???
      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@??? smtp.sender.net 1234567.98765432@???
      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@???> / <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@???> <SP> <orig-server> (optional: <SP> <orig-msg-id>)

   Example:
      BLOCK spammer@??? 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@??? smtp.spamco.com
      S: a000 OK spammer@??? 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@??? 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@???> / <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@???> <SP> <orig-server> <SP> <orig-msg-id><EOL>

   Example:
      C: a003 LISTALLOWED
      S: * David Szego <dszego@???> 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@???> <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@???> 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@???>
      Reply-To:   dszego@???
      To:         dszego@???
      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@???>
      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@???>
      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@???>
      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@???>
      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 (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the author retains all his 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@???

ÿþI?n?t?e?r?n?e?t?-?D?r?a?f?t? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?D?.? ?S?z?e?g?o?
?S?t?a?n?d?a?r?d?s? ?T?r?a?c?k? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?d?a?v?i?d?@?m?i?n?d?s?l?i?p?.?o?r?g?
?D?o?c?u?m?e?n?t?:? ?d?r?a?f?t?-?s?z?e?g?o?-?w?c?o?r?-?o?v?e?r?v?i?e?w?-?0?1?.?t?x?t? ?J?a?n?u?a?r?y? ?2?0?0?6?
?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O?v?e?r?v?i?e?w? ?o?f? ?? W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e?? ?E?x?t?e?n?s?i?o?n?s?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?t?o? ?M?a?i?l? ?D?e?l?i?v?e?r?y? ?a?n?d? ?M?a?i?l? ?T?r?a?n?s?f?e?r? ?P?r?o?t?o?c?o?l?s?
?
?N?e?t?w?o?r?k? ?W?o?r?k?i?n?g? ?G?r?o?u?p? ?
?I?n?t?e?r?n?e?t?-?D?r?a?f?t? ?S?u?b?m?i?s?s?i?o?n??C?a?t?e?g?o?r?y?:? ?S?t?a?n?d?a?r?d?s? ?T?r?a?c?k?
?
?
?S?t?a?t?u?s? ?o?f? ?T?h?i?s? ?M?e?m?o??? ? ? ?T?h?i?s? ?d?o?c?u?m?e?n?t? ?s?p?e?c?i?f?i?e?s? ?a?n? ?I?n?t?e?r?n?e?t? ?s?t?a?n?d?a?r?d?s? ?t?r?a?c?k? ?p?r?o?t?o?c?o?l? ?f?o?r? ?t?h?e? ?I?n?t?e?r?n?e?t? ?c?o?m?m?u?n?i?t?y?,? ?a?n?d? ?r?e?q?u?e?s?t?s? ?d?i?s?c?u?s?s?i?o?n? ?a?n?d? ?s?u?g?g?e?s?t?i?o?n?s? ?f?o?r? ?i?m?p?r?o?v?e?m?e?n?t?s?.? ? ?P?l?e?a?s?e? ?r?e?f?e?r? ?t?o? ?t?h?e? ?c?u?r?r?e?n?t? ?e?d?i?t?i?o?n? ?o?f? ?t?h?e? ?"?I?n?t?e?r?n?e?t? ?O?f?f?i?c?i?a?l? ?P?r?o?t?o?c?o?l? ?S?t?a?n?d?a?r?d?s?"? ?(?S?T?D? ?1?)? ?f?o?r? ?t?h?e? ?s?t?a?n?d?a?r?d?i?z?a?t?i?o?n? ?s?t?a?t?e? ?a?n?d? ?s?t?a?t?u?s? ?o?f? ?t?h?i?s? ?p?r?o?t?o?c?o?l?.? ?
?
? ? ? ?B?y? ?s?u?b?m?i?t?t?i?n?g? ?t?h?i?s? ?I?n?t?e?r?n?e?t?-?D?r?a?f?t?,? ?t?h?e? ?a?u?t?h?o?r? ?r?e?p?r?e?s?e?n?t?s? ?t?h?a?t? ?a?n?y? ?a?p?p?l?i?c?a?b?l?e? ?p?a?t?e?n?t? ?o?r? ?o?t?h?e?r? ?I?P?R? ?c?l?a?i?m?s? ?o?f? ?w?h?i?c?h? ?h?e? ?o?r? ?s?h?e? ?i?s? ?a?w?a?r?e? ?h?a?v?e? ?b?e?e?n? ?o?r? ?w?i?l?l? ?b?e? ?d?i?s?c?l?o?s?e?d?,? ?a?n?d? ?a?n?y? ?o?f? ?w?h?i?c?h? ?h?e? ?o?r? ?s?h?e? ?b?e?c?o?m?e?s? ?a?w?a?r?e? ?w?i?l?l? ?b?e? ?d?i?s?c?l?o?s?e?d?,? ?i?n? ?a?c?c?o?r?d?a?n?c?e? ?w?i?t?h? ?S?e?c?t?i?o?n? ?6? ?o?f? ?B?C?P? ?7?9? ?[?B?C?P?7?9?]?.?? ? ? ?? ? ? ?I?n?t?e?r?n?e?t?-?D?r?a?f?t?s? ?a?r?e? ?w?o?r?k?i?n?g? ?d?o?c?u?m?e?n?t?s? ?o?f? ?t?h?e? ?I?n?t?e?r?n?e?t? ?E?n?g?i?n?e?e?r?i?n?g? ?T?a?s?k? ?F?o?r?c?e? ?(?I?E?T?F?)?,? ?i?t?s? ?a?r?e?a?s?,? ?a?n?d? ?i?t?s? ?w?o?r?k?i?n?g? ?g?r?o?u?p?s?.? ? ?N?o?t?e? ?t?h?a?t? ?o?t?h?e?r? ?g?r?o?u?p?s? ?m?a?y? ?a?l?s?o? ?d?i?s?t?r?i?b?u?t?e? ?w?o?r?k?i?n?g? ?d?o?c?u?m?e?n?t?s? ?a?s? ?I?n?t?e?r?n?e?t?-?D?r?a?f?t?s?.?? ? ? ?? ? ? ?I?n?t?e?r?n?e?t?-?D?r?a?f?t?s? ?a?r?e? ?d?r?a?f?t? ?d?o?c?u?m?e?n?t?s? ?v?a?l?i?d? ?f?o?r? ?a? ?m?a?x?i?m?u?m? ?o?f? ?s?i?x? ?m?o?n?t?h?s? ?a?n?d? ?m?a?y? ?b?e? ?u?p?d?a?t?e?d?,? ?r?e?p?l?a?c?e?d?,? ?o?r? ?o?b?s?o?l?e?t?e?d? ?b?y? ?o?t?h?e?r? ?d?o?c?u?m?e?n?t?s? ?a?t? ?a?n?y? ?t?i?m?e?.? ? ?I?t? ?i?s? ?i?n?a?p?p?r?o?p?r?i?a?t?e? ?t?o? ?u?s?e? ?I?n?t?e?r?n?e?t?-?D?r?a?f?t?s? ?a?s? ?r?e?f?e?r?e?n?c?e? ?m?a?t?e?r?i?a?l? ?o?r? ?t?o? ?c?i?t?e? ?t?h?e?m? ?o?t?h?e?r? ?t?h?a?n? ?a?s? ?"?w?o?r?k? ?i?n? ?p?r?o?g?r?e?s?s?.?"?? ? ? ?? ? ? ?T?h?e? ?l?i?s?t? ?o?f? ?c?u?r?r?e?n?t? ?I?n?t?e?r?n?e?t?-?D?r?a?f?t?s? ?c?a?n? ?b?e? ?a?c?c?e?s?s?e?d? ?a?t?? ? ? ?h?t?t?p?:?/?/?w?w?w?.?i?e?t?f?.?o?r?g?/?i?e?t?f?/?1?i?d?-?a?b?s?t?r?a?c?t?s?.?t?x?t?? ? ? ?? ? ? ?T?h?e? ?l?i?s?t? ?o?f? ?I?n?t?e?r?n?e?t?-?D?r?a?f?t? ?S?h?a?d?o?w? ?D?i?r?e?c?t?o?r?i?e?s? ?c?a?n? ?b?e? ?a?c?c?e?s?s?e?d? ?a?t? ?h?t?t?p?:?/?/?w?w?w?.?i?e?t?f?.?o?r?g?/?s?h?a?d?o?w?.?h?t?m?l?.?? ? ? ?? ? ? ?A? ?r?e?v?i?s?e?d? ?v?e?r?s?i?o?n? ?o?f? ?t?h?i?s? ?d?r?a?f?t? ?d?o?c?u?m?e?n?t? ?w?i?l?l? ?b?e? ?s?u?b?m?i?t?t?e?d? ?t?o? ?t?h?e? ?R?F?C? ?e?d?i?t?o?r? ?a?s? ?a? ?S?t?a?n?d?a?r?d? ?T?r?a?c?k? ?R?F?C? ?f?o?r? ?t?h?e? ?I?n?t?e?r?n?e?t? ?C?o?m?m?u?n?i?t?y?.?
?? ? ? ?D?i?s?c?u?s?s?i?o?n? ?a?n?d? ?s?u?g?g?e?s?t?i?o?n?s? ?f?o?r? ?i?m?p?r?o?v?e?m?e?n?t? ?a?r?e? ?r?e?q?u?e?s?t?e?d?,? ?a?n?d? ?s?h?o?u?l?d? ?b?e? ?s?e?n?t? ?t?o? ?d?a?v?i?d?@?m?i?n?d?s?l?i?p?.?o?r?g? ?.?
?? ? ? ?D?i?s?t?r?i?b?u?t?i?o?n? ?o?f? ?t?h?i?s? ?m?e?m?o? ?i?s? ?u?n?l?i?m?i?t?e?d?.?
?
? ? ? ?C?o?p?y?r?i?g?h?t? ?(?C?)? ?T?h?e? ?I?n?t?e?r?n?e?t? ?S?o?c?i?e?t?y?.? ? ?A?l?l? ?R?i?g?h?t?s? ?R?e?s?e?r?v?e?d?.?
?
?T?a?b?l?e? ?O?f? ?C?o?n?t?e?n?t?s?
?
? ? ? ?1?.? ?A?b?s?t?r?a?c?t?
? ? ? ? ? ? ?1?.?1? ?P?h?a?s?e? ?I?
? ? ? ? ? ? ?1?.?2? ?P?h?a?s?e? ?I?I?
? ? ? ? ? ? ?1?.?3? ?M?o?v?i?n?g? ?t?o? ?a? ?N?e?w? ?S?e?r?v?e?r?/?S?e?r?v?i?c?e?
? ? ? ?2?.? ?F?u?l?l? ?C?o?p?y?r?i?g?h?t? ?S?t?a?t?e?m?e?n?t?
? ? ? ?3?.? ?R?e?f?e?r?e?n?c?e?s?
? ? ? ?4?.? ?A?u?t?h?o?r?'?s? ?A?d?d?r?e?s?s?
?
?
?1?.? ?A?b?s?t?r?a?c?t?
?
? ? ? ?T?h?e? ?g?o?a?l? ?o?f? ?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?E?x?t?e?n?s?i?o?n?s? ?i?s? ?t?o? ?p?r?o?v?i?d?e?,? ?i?n? ?t?h?e? ?s?i?m?p?l?e?s?t? ?a?n?d? ?l?e?a?s?t? ?i?n?t?r?u?s?i?v?e? ?w?a?y? ?p?o?s?s?i?b?l?e? ?(?b?o?t?h? ?p?r?o?g?r?a?m?m?a?t?i?c?a?l?l?y? ?a?n?d? ?t?o? ?t?h?e? ?u?s?e?r?)?,? ?a? ?m?e?t?h?o?d? ?o?f? ?a?v?o?i?d?i?n?g? ?u?n?s?o?l?i?c?i?t?e?d? ?a?n?d? ?u?n?w?a?n?t?e?d? ?e?m?a?i?l? ?w?i?t?h?o?u?t? ?d?r?a?s?t?i?c?a?l?l?y? ?c?h?a?n?g?i?n?g? ?t?h?e? ?i?n?f?r?a?s?t?r?u?c?t?u?r?e? ?o?f? ?t?h?e? ?I?n?t?e?r?n?e?t?'?s? ?e?x?i?s?t?i?n?g? ?m?a?i?l? ?t?r?a?n?s?p?o?r?t?s?.? ? ?T?h?i?s? ?d?o?c?u?m?e?n?t? ?d?e?s?c?r?i?b?e?s? ?a? ?t?w?o?-?p?h?a?s?e? ?e?v?o?l?u?t?i?o?n?a?r?y? ?a?p?p?r?o?a?c?h? ?i?n? ?o?r?d?e?r? ?t?o? ?m?a?i?n?t?a?i?n? ?c?o?m?p?a?t?i?b?i?l?i?t?y? ?w?i?t?h? ?e?x?i?s?t?i?n?g? ?s?t?a?n?d?a?r?d? ?P?O?P?3?/?I?M?A?P?4? ?r?e?t?r?i?e?v?a?l?/?d?e?l?i?v?e?r?y? ?s?e?r?v?e?r?s?,? ?S?M?T?P? ?m?a?i?l? ?t?r?a?n?s?f?e?r? ?a?g?e?n?t?s?,? ?a?n?d? ?e?n?d?-?u?s?e?r? ?m?a?i?l? ?c?l?i?e?n?t?s?.? ?
?
?
?1?.?1? ?P?h?a?s?e? ?I?
?
? ? ? ?P?h?a?s?e? ?I? ?a?l?l?o?w?s? ?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?E?x?t?e?n?s?i?o?n?s? ?f?u?n?c?t?i?o?n?a?l?i?t?y? ?o?v?e?r? ?s?t?a?n?d?a?r?d? ?S?M?T?P? ?m?a?i?l? ?t?r?a?n?s?f?e?r? ?a?g?e?n?t?s?.? ? ?T?h?i?s? ?e?n?t?a?i?l?s? ?a? ?s?o?m?e?w?h?a?t? ?b?a?s?i?c? ?a?d?d?i?t?i?o?n? ?o?f? ?w?h?i?t?e?/?b?l?a?c?k?l?i?s?t? ?f?u?n?c?t?i?o?n?s? ?b?y? ?a?d?d?i?n?g? ?? W?e?l?c?o?m?e?? ,? ?? U?n?w?e?l?c?o?m?e?? ,? ?a?n?d? ?? P?e?n?d?i?n?g?? ?l?i?s?t?s? ?t?o? ?m?a?i?l? ?r?e?t?r?i?e?v?a?l? ?a?n?d? ?d?e?l?i?v?e?r?y? ?s?e?r?v?e?r?s?.? ? ?T?h?e?s?e? ?c?a?n? ?b?e? ?P?O?P?,? ?I?M?A?P?,? ?o?r? ?o?t?h?e?r? ?n?o?n?-?s?t?a?n?d?a?r?d? ?p?r?o?t?o?c?o?l?s? ?w?h?i?c?h? ?i?n?t?e?r?a?c?t? ?w?i?t?h? ?S?M?T?P? ?a?n?d? ?c?h?o?o?s?e? ?t?o? ?i?m?p?l?e?m?e?n?t? ?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?E?x?t?e?n?s?i?o?n?s?.? ? ?T?h?e?s?e? ?W?e?l?c?o?m?e?,? ?U?n?w?e?l?c?o?m?e? ?a?n?d? ?P?e?n?d?i?n?g? ?l?i?s?t?s? ?a?r?e? ?m?a?i?n?t?a?i?n?e?d? ?o?n? ?t?h?e? ?u?s?e?r?s? ?m?a?i?l? ?d?e?l?i?v?e?r?y? ?s?e?r?v?e?r? ?i?n? ?o?r?d?e?r? ?t?o? ?a?v?o?i?d? ?d?u?p?l?i?c?a?t?i?o?n? ?o?f? ?? J?u?n?k? ?S?e?n?d?e?r?? ?a?n?d? ?b?l?a?c?k?l?i?s?t?s? ?a?c?r?o?s?s? ?m?u?l?t?i?p?l?e? ?m?a?i?l? ?c?l?i?e?n?t?s?.? ? ?T?h?i?s? ?a?v?o?i?d?s? ?c?l?i?e?n?t? ?s?y?n?c?h?r?o?n?i?z?a?t?i?o?n? ?p?r?o?b?l?e?m?s? ?a?n?d? ?f?r?u?s?t?r?a?t?i?o?n?s? ?t?o? ?t?h?e? ?u?s?e?r?,? ?a?n?d? ?a?l?l?o?w?s? ?m?i?g?r?a?t?i?o?n? ?o?f? ?u?s?e?r?s? ?t?o? ?n?e?w? ?m?a?i?l? ?s?e?r?v?e?r?s?/?s?e?r?v?i?c?e?s? ?b?y? ?s?y?n?c?h?i?n?g? ?l?i?s?t?s? ?b?e?t?w?e?e?n? ?o?l?d? ?a?n?d? ?n?e?w? ?s?e?r?v?e?r?s? ?a?n?d? ?a?l?e?r?t?i?n?g? ?W?e?l?c?o?m?e? ?s?e?n?d?e?r?s?.?
?
? ? ? ?N?o?t?e? ?t?h?a?t? ?a?l?l? ?m?a?i?l? ?c?l?i?e?n?t?s? ?a?n?d? ?d?e?l?i?v?e?r?y? ?s?e?r?v?e?r?s? ?(?P?O?P?/?I?M?A?P?,? ?e?t?c?)? ?w?h?i?c?h? ?s?u?p?p?o?r?t? ?a?n?y? ?W?C?-?E?x?t?e?n?s?i?o?n?s? ?m?u?s?t? ?s?u?p?p?o?r?t? ?W?C?-?I?I? ?(?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?E?x?t?e?n?s?i?o?n?s?,? ?P?h?a?s?e? ?I?I?)? ?b?u?t? ?w?i?l?l? ?o?p?e?r?a?t?e? ?i?n? ?W?C?-?I? ?(?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?E?x?t?e?n?s?i?o?n?s?,? ?P?h?a?s?e?-?I?)? ?m?o?d?e? ?w?h?e?n? ?i?n?t?e?r?a?c?t?i?n?g? ?w?i?t?h? ?n?o?n?-?W?C?-?c?o?m?p?l?i?a?n?t? ?m?a?i?l? ?t?r?a?n?s?f?e?r? ?a?g?e?n?t?s? ?o?r? ?m?a?i?l? ?c?l?i?e?n?t?s?.?
?
? ? ? ?W?i?t?h? ?a? ?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?? ?P?h?a?s?e? ?I? ?(?? W?C?-?I?? )? ?i?m?p?l?e?m?e?n?t?a?t?i?o?n?,? ?n?e?w? ?? C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?R?e?q?u?e?s?t?s?? ?a?r?e? ?g?e?n?e?r?a?t?e?d? ?u?p?o?n? ?r?e?c?e?i?p?t? ?o?f? ?a?n? ?e?m?a?i?l? ?f?r?o?m? ?a?n? ?a?d?d?r?e?s?s? ?n?o?t? ?p?r?e?s?e?n?t? ?i?n? ?e?i?t?h?e?r? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?W?e?l?c?o?m?e?,? ?U?n?w?e?l?c?o?m?e?,? ?o?r? ?P?e?n?d?i?n?g? ?l?i?s?t?s?.? ? ?T?h?i?s? ?r?e?q?u?e?s?t? ?M?U?S?T? ?b?e? ?p?r?e?s?e?n?t?e?d? ?t?o? ?t?h?e? ?u?s?e?r? ?i?n? ?e?i?t?h?e?r? ?a?n? ?e?m?a?i?l?,? ?o?r? ?a? ?? N?e?w? ?C?o?r?r?e?s?p?o?n?d?e?n?t?s?? ?l?i?s?t?,? ?d?e?p?e?n?d?i?n?g? ?o?n? ?w?h?e?t?h?e?r? ?o?r? ?n?o?t? ?t?h?e? ?e?m?a?i?l? ?c?l?i?e?n?t? ?i?d?e?n?t?i?f?i?e?s? ?i?t?s?e?l?f? ?a?s? ?W?C?-?I? ?c?o?m?p?a?t?i?b?l?e?.? ? ?U?s?e?r?s? ?h?a?v?e? ?t?h?e? ?c?h?o?i?c?e? ?o?f? ?a?l?l?o?w?i?n?g? ?o?r? ?b?l?o?c?k?i?n?g? ?e?m?a?i?l? ?f?r?o?m? ?t?h?e? ?s?e?n?d?e?r?,? ?o?r? ?l?e?a?v?i?n?g? ?a? ?r?e?q?u?e?s?t? ?u?n?a?n?s?w?e?r?e?d? ?i?n? ?w?h?i?c?h? ?c?a?s?e? ?t?h?e? ?e?m?a?i?l? ?i?n? ?q?u?e?s?t?i?o?n? ?M?A?Y? ?b?e? ?d?e?l?i?v?e?r?e?d? ?f?o?r? ?r?e?v?i?e?w?,? ?b?u?t? ?f?u?r?t?h?e?r? ?e?m?a?i?l?s? ?f?r?o?m? ?t?h?i?s? ?s?e?n?d?e?r? ?M?U?S?T? ?N?O?T? ?b?e? ?d?e?l?i?v?e?r?e?d? ?u?n?t?i?l? ?t?h?e? ?s?e?n?d?e?r? ?i?s? ?a?d?d?e?d? ?t?o? ?t?h?e? ?W?e?l?c?o?m?e? ?l?i?s?t?.?
?
? ? ? ?I?f?,? ?u?p?o?n? ?l?o?g?i?n? ?t?o? ?a? ?W?C?-?I? ?c?o?m?p?a?t?i?b?l?e? ?d?e?l?i?v?e?r?y? ?s?e?r?v?e?r?,? ?a? ?c?l?i?e?n?t? ?d?o?e?s? ?n?o?t? ?i?d?e?n?t?i?f?y? ?i?t?s?e?l?f? ?a?s? ?W?C?-?I? ?c?o?m?p?a?t?i?b?l?e?,? ?a?n? ?e?m?a?i?l? ?M?U?S?T? ?b?e? ?g?e?n?e?r?a?t?e?d? ?b?y? ?t?h?e? ?d?e?l?i?v?e?r?y? ?s?e?r?v?e?r? ?l?i?s?t?i?n?g? ?n?e?w? ?a?n?d? ?p?e?n?d?i?n?g? ?r?e?q?u?e?s?t?s? ?a?n?d? ?p?r?o?v?i?d?i?n?g? ?i?n?t?e?r?n?a?l? ?r?e?p?l?y?-?t?o? ?a?d?d?r?e?s?s?e?s? ?f?o?r? ?e?a?c?h? ?o?f? ?t?h?e? ?t?h?r?e?e? ?p?o?s?s?i?b?l?e? ?a?c?t?i?o?n?s? ?(?A?l?l?o?w?,? ?B?l?o?c?k?,? ?o?r? ?L?e?a?v?e? ?P?e?n?d?i?n?g?)?.? ? ?T?h?e? ?u?s?e?r? ?M?A?Y? ?r?e?p?l?y? ?u?s?i?n?g? ?t?h?e? ?g?i?v?e?n? ?m?a?i?l?-?t?o? ?l?i?n?k? ?f?o?r? ?e?a?c?h? ?c?h?o?i?c?e?,? ?s?e?n?d?i?n?g? ?a?n? ?e?m?a?i?l? ?t?o? ?t?h?e?m?s?e?l?v?e?s? ?w?h?i?c?h? ?M?U?S?T? ?B?E? ?i?n?t?e?r?c?e?p?t?e?d? ?b?y? ?t?h?e? ?W?C?-?I? ?r?e?t?r?i?e?v?a?l? ?s?e?r?v?e?r? ?d?i?r?e?c?t?l?y?,? ?a?n?d? ?a?c?t?e?d? ?u?p?o?n?.? ? ?T?h?i?s? ?i?s? ?a?n?a?l?o?g?o?u?s? ?t?o? ?c?o?n?t?r?o?l?l?i?n?g? ?M?a?i?l?i?n?g? ?L?i?s?t? ?s?u?b?s?c?r?i?p?t?i?o?n?s? ?b?y? ?m?a?i?l? ?c?o?m?m?a?n?d?s? ?s?e?n?t? ?t?o? ?t?h?e? ?m?a?i?l?i?n?g? ?l?i?s?t? ?s?e?r?v?e?r?.?
?
?
? ? ? ? ? ? ?F?r?o?m?:? ? ? ? ? ? ?W?C?-?I?-?S?e?r?v?e?r? ?<?d?s?z?e?g?o?@?m?i?n?d?s?l?i?p?.?c?o?m?>? ?
? ? ? ? ? ? ?R?e?p?l?y?-?T?o?:? ? ?d?s?z?e?g?o?@?m?i?n?d?s?l?i?p?.?c?o?m? ?
? ? ? ? ? ? ?T?o?:? ? ? ? ? ? ? ? ?d?s?z?e?g?o?@?m?i?n?d?s?l?i?p?.?c?o?m? ?
? ? ? ? ? ? ?S?u?b?j?e?c?t?:? ? ? ?N?e?w? ?a?n?d? ?P?e?n?d?i?n?g? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?R?e?q?u?e?s?t?s? ?
? ? ? ? ? ? ?D?a?t?e?:? ? ? ? ? ? ?F?r?i?,? ?1?6? ?J?a?n? ?2?0?0?4? ?1?7?:?0?2?:?0?8? ?-?0?5?0?0? ?
?
? ? ? ? ? ? ?T?h?i?s? ?i?s? ?t?h?e? ?m?a?i?l? ?s?e?r?v?e?r? ?a?t? ?p?o?p?3?.?i?n?c?o?m?i?n?g?.?c?o?m? ?
? ? ? ? ? ? ?Y?o?u? ?h?a?v?e? ?3? ?n?e?w?,? ?a?n?d? ?1? ?p?e?n?d?i?n?g? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?R?e?q?u?e?s?t?s?:? ?
?
? ? ? ? ? ? ?N?e?w?:? ?
?
? ? ? ? ? ? ?F?r?o?m?:? ? ? ? ? ? ? ? ? ? ? ?J?o?h?n? ?D?o?e?,? ?j?d?o?e?@?s?e?n?d?e?r?.?n?e?t? ?
? ? ? ? ? ? ?S?u?b?j?e?c?t?:? ? ? ? ? ? ? ? ?B?u?y? ?p?h?a?r?m?a?c?e?u?t?i?c?a?l?s? ?o?n?l?i?n?e?!? ?
? ? ? ? ? ? ?[?A?l?l?o?w? ?t?h?i?s? ?s?e?n?d?e?r?]? ?<?m?a?i?l?t?o?:?d?s?z?e?g?o?@?m?i?n?d?s?l?i?p?.?c?o?m???s?u?b?j?e?c?t?=?<?s?o?m?e?u?i?d?>?A?l?l?o?w?>? ?
? ? ? ? ? ? ?[?B?l?o?c?k? ?t?h?i?s? ?s?e?n?d?e?r?]? ?<?m?a?i?l?t?o?:?d?s?z?e?g?o?@?m?i?n?d?s?l?i?p?.?c?o?m???s?u?b?j?e?c?t?=?<?s?o?m?e?u?i?d?>?B?l?o?c?k?>? ?
?
? ? ? ? ? ? ?F?r?o?m?:? ? ? ? ? ? ? ? ? ? ? ?J?o?e? ?B?l?o?w?,? ?j?o?e?.?b?l?o?w?@?y?a?h?o?o?.?c?o?m? ?
? ? ? ? ? ? ?S?u?b?j?e?c?t?:? ? ? ? ? ? ? ? ?R?e?:? ?M?e?e?t?i?n?g? ?n?e?x?t? ?t?h?u?r?s?d?a?y? ?
? ? ? ? ? ? ?[?A?l?l?o?w? ?t?h?i?s? ?s?e?n?d?e?r?]? ?<?m?a?i?l?t?o?:?d?s?z?e?g?o?@?m?i?n?d?s?l?i?p?.?c?o?m???s?u?b?j?e?c?t?=?<?s?o?m?e?u?i?d?>?A?l?l?o?w?>? ?
? ? ? ? ? ? ?[?B?l?o?c?k? ?t?h?i?s? ?s?e?n?d?e?r?]? ?<?m?a?i?l?t?o?:?d?s?z?e?g?o?@?m?i?n?d?s?l?i?p?.?c?o?m???s?u?b?j?e?c?t?=?<?s?o?m?e?u?i?d?>?B?l?o?c?k?>? ?
?
? ? ? ? ? ? ?F?r?o?m?:? ? ? ? ? ? ? ? ? ? ? ?C?a?i?n? ?A?b?l?e?,? ?c?a?b?l?e?@?i?s?p?.?n?e?t? ?
? ? ? ? ? ? ?S?u?b?j?e?c?t?:? ? ? ? ? ? ? ? ?M?e?e?t? ?p?e?o?p?l?e? ?i?n? ?y?o?u?r? ?a?r?e?a? ?a?d?s?f?8?7?s?d?a? ?
? ? ? ? ? ? ?[?A?l?l?o?w? ?t?h?i?s? ?s?e?n?d?e?r?]? ?<?m?a?i?l?t?o?:?d?s?z?e?g?o?@?m?i?n?d?s?l?i?p?.?c?o?m???s?u?b?j?e?c?t?=?<?s?o?m?e?u?i?d?>?A?l?l?o?w?>? ?
? ? ? ? ? ? ?[?B?l?o?c?k? ?t?h?i?s? ?s?e?n?d?e?r?]? ?<?m?a?i?l?t?o?:?d?s?z?e?g?o?@?m?i?n?d?s?l?i?p?.?c?o?m???s?u?b?j?e?c?t?=?<?s?o?m?e?u?i?d?>?B?l?o?c?k?>? ?
?
? ? ? ? ? ? ?P?e?n?d?i?n?g?:? ?
?
? ? ? ? ? ? ?F?r?o?m?:? ? ? ? ? ? ? ? ? ? ? ?A?l? ?P?h?a?b?e?t?,? ?a?b?c?d?e?@?x?y?z?.?c?o?m? ?
? ? ? ? ? ? ?S?u?b?j?e?c?t?:? ? ? ? ? ? ? ? ?U?r?g?e?n?t? ?r?e?q?u?e?s?t? ?f?o?r? ?h?e?l?p? ?
? ? ? ? ? ? ?[?A?l?l?o?w? ?t?h?i?s? ?s?e?n?d?e?r?]? ?<?m?a?i?l?t?o?:?d?s?z?e?g?o?@?m?i?n?d?s?l?i?p?.?c?o?m???s?u?b?j?e?c?t?=?<?s?o?m?e?u?i?d?>?A?l?l?o?w?>? ?
? ? ? ? ? ? ?[?B?l?o?c?k? ?t?h?i?s? ?s?e?n?d?e?r?]? ?<?m?a?i?l?t?o?:?d?s?z?e?g?o?@?m?i?n?d?s?l?i?p?.?c?o?m???s?u?b?j?e?c?t?=?<?s?o?m?e?u?i?d?>?B?l?o?c?k?>? ?
? ? ? ? ? ? ?P?e?n?d?i?n?g? ?s?i?n?c?e? ?0?1?/?0?1?/?2?0?0?4?
???
? ? ? ?I?f? ?a? ?c?l?i?e?n?t? ?i?d?e?n?t?i?f?i?e?s? ?i?t?s?e?l?f? ?t?o? ?t?h?e? ?s?e?r?v?e?r? ?a?s? ?W?C?-?I? ?c?o?m?p?a?t?i?b?l?e?,? ?a? ?? N?e?w? ?C?o?r?r?e?s?p?o?n?d?e?n?t?s?? ?l?i?s?t? ?w?i?l?l? ?b?e? ?s?e?n?t? ?t?o? ?t?h?e? ?c?l?i?e?n?t? ?f?o?r? ?p?r?e?s?e?n?t?a?t?i?o?n? ?i?n? ?a? ?m?a?n?n?e?r? ?a?p?p?l?i?c?a?b?l?e? ?t?o? ?t?h?e? ?l?o?o?k? ?a?n?d? ?f?e?e?l? ?o?f? ?t?h?e? ?c?l?i?e?n?t? ?i?n?t?e?r?f?a?c?e?/?O?S?.? ? ?T?h?e? ?u?s?e?r? ?m?a?y? ?s?e?l?e?c?t? ?a?n? ?a?c?t?i?o?n? ?f?o?r? ?e?a?c?h? ?r?e?q?u?e?s?t?,? ?w?h?i?c?h? ?i?s? ?c?o?m?m?u?n?i?c?a?t?e?d? ?d?i?r?e?c?t?l?y? ?t?o? ?t?h?e? ?W?C?-?I? ?d?e?l?i?v?e?r?y? ?s?e?r?v?e?r? ?b?y? ?t?h?e? ?W?C?-?I? ?c?l?i?e?n?t?.?
?
?
? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+?
? ? ? ? ? ? ?|?[?]? ?N?e?w? ?a?n?d? ?P?e?n?d?i?n?g? ?C?o?r?r?e?s?p?o?n?d?e?n?t?s? ? ? ?-? ?+? ?X? ?|?
? ? ? ? ? ? ?|?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?|?
? ? ? ? ? ? ?|?+?-? ?N?e?w? ?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+?|?
? ? ? ? ? ? ?|?|? ?J?o?h?n? ?D?o?e? ?j?d?o?e?@?s?e?n?d?e?r?.?n?e?t? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ?|?|?
? ? ? ? ? ? ?|?|? ?B?u?y? ?p?h?a?r?m?e?c?e?u?t?i?c?a?l?s? ?o?n?l?i?n?e?!? ? ?|? ?A?l?l?o?w? ?|? ?|?|?
? ? ? ? ? ? ?|?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ?|?|?
? ? ? ? ? ? ?|?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ?|?|?
? ? ? ? ? ? ?|?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ?B?l?o?c?k? ?|? ?|?|?
? ? ? ? ? ? ?|?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ?|?|?
? ? ? ? ? ? ?|?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+?|?
? ? ? ? ? ? ?|?+?-? ?P?e?n?d?i?n?g? ?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+?|?
? ? ? ? ? ? ?|?|? ?A?l? ?P?h?a?b?e?t? ?a?b?c?d?e?@?x?y?z?.?c?o?m? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ?|?|?
? ? ? ? ? ? ?|?|? ?U?r?g?e?n?t? ?r?e?q?u?e?s?t? ?f?o?r? ?h?e?l?p?!? ? ? ? ? ?|? ?A?l?l?o?w? ?|? ?|?|?
? ? ? ? ? ? ?|?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ?|?|?
? ? ? ? ? ? ?|?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ?|?|?
? ? ? ? ? ? ?|?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ?B?l?o?c?k? ?|? ?|?|?
? ? ? ? ? ? ?|?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ?|?|?
? ? ? ? ? ? ?|?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+?|?
? ? ? ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?+? ?+?-?-?-?-?+? ?|?
? ? ? ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ?C?a?n?c?e?l? ?|? ?|? ?O?K? ?|? ?|?
? ? ? ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?+? ?+?-?-?-?-?+? ?|?
? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+?
?
?
?üÿ ? ? ?W?h?e?n? ?a? ?u?s?e?r? ?d?e?c?i?d?e?s? ?o?n? ?a?n? ?a?c?t?i?o?n? ?f?o?r? ?a? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?R?e?q?u?e?s?t?,? ?t?h?e? ?W?C?-?I? ?c?o?m?p?a?t?i?b?l?e? ?s?e?r?v?e?r? ?a?d?d?s? ?t?h?e? ?s?e?n?d?e?r?'?s? ?e?m?a?i?l? ?a?d?d?r?e?s?s? ?a?n?d? ?o?r?i?g?i?n?a?t?i?n?g? ?s?e?r?v?e?r? ?(?t?a?k?e?n? ?f?r?o?m? ?t?h?e? ?S?M?T?P? ?R?e?t?u?r?n?-?P?a?t?h? ?h?e?a?d?e?r?)? ?t?o? ?t?h?e? ?u?s?e?r?s? ?W?e?l?c?o?m?e? ?o?r? ?U?n?w?e?l?c?o?m?e? ?l?i?s?t? ?a?s? ?a?p?p?r?o?p?r?i?a?t?e?.? ? ?T?h?e? ?e?n?t?r?y? ?M?U?S?T? ?b?e? ?r?e?m?o?v?e?d? ?f?r?o?m? ?t?h?e? ?P?e?n?d?i?n?g? ?l?i?s?t? ?i?f? ?t?h?i?s? ?w?a?s? ?a? ?p?r?e?v?i?o?u?s?l?y? ?p?e?n?d?i?n?g? ?s?e?n?d?e?r?.?
?
? ? ? ?I?n?c?o?m?i?n?g? ?e?m?a?i?l?s? ?w?h?o?s?e? ?s?e?n?d?e?r?/?s?e?r?v?e?r? ?m?a?t?c?h? ?a?n? ?e?x?i?s?t?i?n?g? ?W?e?l?c?o?m?e? ?o?r? ?U?n?w?e?l?c?o?m?e? ?e?n?t?r?y? ?M?U?S?T? ?b?e? ?d?e?l?i?v?e?r?e?d? ?o?r? ?w?i?t?h?h?e?l?d? ?a?s? ?a?p?p?r?o?p?r?i?a?t?e?.? ? ?E?m?a?i?l?s? ?w?h?o?s?e? ?s?e?n?d?e?r?/?s?e?r?v?e?r? ?m?a?t?c?h?e?s? ?a? ?P?e?n?d?i?n?g? ?e?n?t?r?y? ?M?U?S?T? ?b?e? ?t?e?m?p?o?r?a?r?i?l?y? ?t?r?e?a?t?e?d? ?a?s? ?U?n?w?e?l?c?o?m?e?,? ?a?n?d? ?t?h?e? ?P?e?n?d?i?n?g? ?e?n?t?r?y? ?M?U?S?T? ?r?e?m?a?i?n? ?i?n? ?t?h?e? ?u?s?e?r?'?s? ?N?e?w? ?C?o?r?r?e?s?p?o?n?d?e?n?t?s? ?l?i?s?t? ?u?n?t?i?l? ?a?c?t?e?d? ?u?p?o?n?.? ? ?T?h?e? ?s?e?n?d?e?r?s? ?a?d?d?r?e?s?s? ?w?i?l?l? ?n?o?t? ?b?e? ?d?u?p?l?i?c?a?t?e?d? ?i?n? ?t?h?e? ?N?e?w? ?C?o?r?r?e?s?p?o?n?d?e?n?t?s? ?l?i?s?t? ?u?n?l?e?s?s? ?t?h?e? ?a?d?d?r?e?s?s? ?i?s? ?s?e?e?n? ?c?o?m?i?n?g? ?f?r?o?m? ?a? ?n?e?w? ?s?e?r?v?e?r?,? ?i?n? ?w?h?i?c?h? ?c?a?s?e? ?i?t? ?w?i?l?l? ?b?e? ?t?r?e?a?t?e?d? ?a?s? ?a? ?n?e?w? ?e?n?t?r?y?.? ? ?P?e?n?d?i?n?g? ?l?i?s?t?s? ?M?U?S?T? ?a?l?s?o? ?c?o?n?t?a?i?n? ?t?h?e? ?s?u?b?j?e?c?t? ?l?i?n?e? ?o?f? ?t?h?e? ?i?n?i?t?i?a?l? ?c?o?n?t?a?c?t? ?e?m?a?i?l?,? ?a?s? ?a? ?r?e?m?i?n?d?e?r? ?t?o? ?t?h?e? ?r?e?c?i?p?i?e?n?t? ?w?h?e?n? ?b?r?o?w?s?i?n?g? ?l?o?n?g?-?s?t?a?n?d?i?n?g? ?P?e?n?d?i?n?g? ?r?e?q?u?e?s?t?s?.?
?
? ? ? ?N?o?t?i?f?i?c?a?t?i?o?n? ?o?f? ?a?d?d?i?t?i?o?n?s? ?t?o? ?a? ?u?s?e?r?s? ?U?n?w?e?l?c?o?m?e? ?l?i?s?t? ?M?U?S?T? ?N?O?T? ?b?e? ?g?e?n?e?r?a?t?e?d?,? ?t?o? ?a?v?o?i?d? ?c?o?n?f?i?r?m?a?t?i?o?n? ?o?f? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?e?x?i?s?t?e?n?c?e? ?t?o? ?s?p?a?m? ?s?e?r?v?e?r?s? ?w?h?i?c?h? ?m?a?y? ?f?l?o?o?d? ?t?h?e? ?r?e?c?i?p?i?e?n?t? ?w?i?t?h? ?f?u?t?u?r?e? ?e?m?a?i?l?s? ?f?r?o?m? ?b?o?g?u?s? ?a?d?d?r?e?s?s?e?s?,? ?t?h?u?s? ?f?i?l?l?i?n?g? ?t?h?e? ?N?e?w? ?C?o?r?r?e?s?p?o?n?d?e?n?t?s? ?l?i?s?t? ?w?i?t?h? ?b?o?g?u?s? ?e?n?t?r?i?e?s?.?
?
?
?+?-?-?-?+? ?N?e?w? ?E?m?a?i?l?:?
?|? ? ? ?|? ?T?o?:? ?r?e?c?i?p?i?e?n?t?@?i?n?c?o?m?i?n?g?.?c?o?m?
?+?-?-?-?+? ?F?r?o?m?:? ?s?e?n?d?e?r?@?o?u?t?g?o?i?n?g?.?n?e?t?
? ? ?|?
? ? ?|? ? ?1? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+?
? ?\?|?/? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?>?|?W?e?l?c?o?m?e?|?<?-?-?-?+?
?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ? ? ? ? ? ?|? ? ?+?-?-?-?-?-?-?-?+? ? ? ? ?|?
?|?O?u?t?g?o?i?n?g? ?M?T?A? ?(?n?o?n?-?W?C?)?|? ? ?2? ? ? ?|?I?n?c?o?m?i?n?g? ?M?T?A? ?(?n?o?n?-?W?C?)?|? ? ? ? ? ? ?|? ? ?+?-?-?-?-?-?-?-?-?-?+? ? ?|?
?|? ? ?s?m?t?p?.?o?u?t?g?o?i?n?g?.?n?e?t? ? ?|?-?>?-?-?-?>?|? ? ?s?m?t?p?.?i?n?c?o?m?i?n?g?.?c?o?m? ? ?|? ? ? ? ? ? ?+?-?>?|?U?n?w?e?l?c?o?m?e?|?<?-?+? ?9?
?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ? ? ?^? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ? ? ? ?4? ?|? ? ?+?-?-?-?-?-?-?-?-?-?+? ? ?|?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ? ? ? ? ?|? ? ? ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?8? ?|? ? ?+?-?-?-?-?-?-?-?+? ? ? ? ?|?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ? ? ? ? ?|? ?3? ? ? ? ?|? ?7?a? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?>?|?P?e?n?d?i?n?g?|?-?>?-?-?+?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ? ? ? ?\?|?/? ? ? ? ?\?|?/? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ?+?-?-?-?-?-?-?-?+?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ? ?|? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ?|?I?n?c?o?m?i?n?g? ?d?e?l?i?v?e?r?y? ?(?W?C?-?I?I?)?|?-?>?+?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ?|? ? ?p?o?p?-?i?m?a?p?.?i?n?c?o?m?i?n?g?.?c?o?m? ? ?|?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?6?a? ?|? ? ? ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ? ? ? ?^?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ? ? ? ? ?|? ?5?a? ? ? ? ? ? ? ? ? ? ?|? ?5?b? ? ?|? ?6?b?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ? ? ? ?\?|?/? ? ? ? ? ? ? ? ? ? ? ?\?|?/? ? ? ? ?|?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|?E?m?a?i?l? ?c?l?i?e?n?t? ?(?n?o?n?-?W?C?)? ?|? ?|? ?E?m?a?i?l? ?c?l?i?e?n?t? ?(?W?C?-?I?I?)? ?|?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|?r?e?c?i?p?i?e?n?t?@?i?n?c?o?m?i?n?g?.?c?o?m?|? ?|?r?e?c?i?p?i?e?n?t?@?i?n?c?o?m?i?n?g?.?c?o?m?|?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+?
?üÿ
?F?i?g?u?r?e? ?2?:? ?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?P?h?a?s?e? ?I?
?
?
?1?.?2? ?P?h?a?s?e? ?I?I?
?
? ? ? ?P?h?a?s?e? ?I?I? ?e?x?t?e?n?d?s? ?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?w?h?i?t?e?/?b?l?a?c?k?l?i?s?t? ?f?u?n?c?t?i?o?n?s? ?t?o? ?t?h?e? ?S?M?T?P? ?M?a?i?l? ?T?r?a?n?s?f?e?r? ?s?e?r?v?e?r?s?,? ?a?l?l?o?w?i?n?g? ?f?o?r? ?a? ?m?o?r?e? ?a?u?t?o?m?a?t?e?d? ?m?e?t?h?o?d? ?o?f? ?c?o?n?f?i?r?m?i?n?g? ?w?h?e?t?h?e?r? ?a? ?s?e?n?d?e?r? ?i?s? ?w?e?l?c?o?m?e? ?o?r? ?n?o?t?,? ?w?i?t?h? ?l?e?s?s? ?u?s?e?r? ?i?n?t?e?r?a?c?t?i?o?n?.? ? ?T?h?i?s? ?i?s? ?d?o?n?e? ?b?y? ?a?l?l?o?w?i?n?g? ?i?n?t?e?r?a?c?t?i?o?n? ?b?e?t?w?e?e?n? ?t?h?e? ?S?M?T?P? ?s?e?r?v?e?r? ?(?o?r? ?m?a?i?l? ?g?a?t?e?w?a?y?)?,? ?a?n?d? ?t?h?e? ?W?e?l?c?o?m?e?d?/?U?n?w?e?l?c?o?m?e?/?P?e?n?d?i?n?g? ?l?i?s?t?s? ?d?i?r?e?c?t?l?y?.?
?
? ? ? ?W?h?e?n? ?s?e?n?d?i?n?g? ?a?n? ?e?m?a?i?l? ?t?o? ?a? ?n?e?w? ?r?e?c?i?p?i?e?n?t?,? ?a? ?W?C?-?I?I? ?c?o?m?p?a?t?i?b?l?e? ?S?M?T?P? ?s?e?r?v?e?r? ?a?d?d?s? ?a?n? ?? <?o?r?i?g?-?s?e?r?v?e?r?>?? ?h?e?a?d?e?r? ?t?o? ?t?h?e? ?e?m?a?i?l?,? ?a?n?d? ?a?d?d?s? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?a?d?d?r?e?s?s? ?t?o? ?b?o?t?h? ?t?h?e? ?s?e?n?d?e?r?s? ?W?e?l?c?o?m?e? ?a?n?d? ?P?e?n?d?i?n?g? ?l?i?s?t?s?,? ?a?s? ?w?e?l?l? ?a?s? ?a?d?d?i?n?g? ?t?h?e? ?e?m?a?i?l?'?s? ?S?M?T?P? ?M?e?s?s?a?g?e? ?I?D? ?t?o? ?t?h?e? ?s?e?n?d?e?r?s? ?P?e?n?d?i?n?g? ?l?i?s?t? ?a?s? ?a?n? ?? <?o?r?i?g?-?m?s?g?-?i?d?>?? .? ? ?T?h?i?s? ?i?s? ?d?o?n?e? ?t?o? ?i?n?d?i?c?a?t?e? ?t?h?a?t? ?a? ?r?e?p?l?y? ?e?m?a?i?l? ?f?r?o?m? ?t?h?i?s? ?r?e?c?i?p?i?e?n?t? ?w?o?u?l?d? ?b?e? ?w?e?l?c?o?m?e?d?,? ?a?s? ?t?h?e? ?s?e?n?d?e?r? ?h?a?s? ?i?n?i?t?i?a?t?e?d? ?c?o?n?t?a?c?t?,? ?t?h?u?s? ?r?e?m?o?v?i?n?g? ?t?h?e? ?n?e?e?d? ?f?o?r? ?f?u?r?t?h?e?r? ?i?n?t?e?r?v?e?n?t?i?o?n? ?b?y? ?t?h?e? ?s?e?n?d?e?r?.? ? ?T?h?e? ?r?e?c?e?i?v?i?n?g? ?m?a?i?l? ?g?a?t?e?w?a?y?,? ?i?f? ?W?C?-?I?I? ?c?o?m?p?a?t?i?b?l?e?,? ?t?h?e?n? ?l?o?o?k?s? ?f?o?r? ?t?h?e? ?s?e?n?d?e?r?'?s? ?a?d?d?r?e?s?s? ?a?n?d? ?o?r?i?g?i?n?a?t?i?n?g? ?s?e?r?v?e?r? ?i?n? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?l?i?s?t?s? ?(?e?i?t?h?e?r? ?f?r?o?m? ?t?h?e? ?<?o?r?i?g?-?s?e?r?v?e?r?>? ?h?e?a?d?e?r? ?i?f? ?p?r?e?s?e?n?t? ?o?r? ?f?r?o?m? ?t?h?e? ?S?M?T?P? ?R?e?p?l?y?-?P?a?t?h? ?h?e?a?d?e?r?)?.? ? ?I?f? ?t?h?e? ?c?o?m?b?i?n?a?t?i?o?n? ?i?s? ?f?o?u?n?d? ?i?n? ?e?i?t?h?e?r? ?t?h?e? ?W?e?l?c?o?m?e? ?o?r? ?U?n?w?e?l?c?o?m?e? ?l?i?s?t?,? ?t?h?e? ?s?e?r?v?e?r? ?a?c?t?s? ?a?p?p?r?o?p?r?i?a?t?e?l?y?.? ? ?I?f? ?t?h?e? ?s?e?n?d?e?r?'?s? ?e?m?a?i?l? ?a?d?d?r?e?s?s? ?i?s? ?n?o?t? ?f?o?u?n?d?,? ?i?t? ?i?s? ?a?d?d?e?d? ?t?o? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?P?e?n?d?i?n?g? ?l?i?s?t?,? ?a?l?o?n?g? ?w?i?t?h? ?t?h?e? ?<?o?r?i?g?-?s?e?r?v?e?r?>?,? ?s?u?b?j?e?c?t? ?l?i?n?e?,? ?a?n?d? ?<?o?r?i?g?-?m?s?g?-?i?d?>?.?
?
? ? ? ?I?f? ?f?u?r?t?h?e?r? ?e?m?a?i?l?s? ?a?r?e? ?s?e?n?t? ?t?o? ?a? ?r?e?c?i?p?i?e?n?t? ?w?h?o? ?i?s? ?p?r?e?s?e?n?t? ?i?n? ?t?h?e? ?s?e?n?d?e?r?'?s? ?P?e?n?d?i?n?g? ?a?n?d? ?W?e?l?c?o?m?e? ?l?i?s?t?,? ?i?t? ?i?s? ?a?s?s?u?m?e?d? ?t?h?a?t? ?t?h?e? ?e?m?a?i?l? ?w?i?l?l? ?n?o?t? ?y?e?t? ?b?e? ?a?c?c?e?p?t?e?d? ?b?y? ?t?h?e? ?r?e?c?i?p?i?e?n?t? ?a?n?d? ?t?h?e? ?m?a?i?l? ?t?r?a?n?s?f?e?r? ?a?g?e?n?t? ?M?U?S?T? ?N?O?T? ?a?c?c?e?p?t? ?s?u?b?m?i?s?s?i?o?n? ?o?f? ?t?h?e? ?e?m?a?i?l? ?f?o?r? ?d?e?l?i?v?e?r?y?.? ? ?A?n? ?a?p?p?r?o?p?r?i?a?t?e? ?b?o?u?n?c?e? ?n?o?t?i?f?i?c?a?t?i?o?n? ?S?H?O?U?L?D? ?b?e? ?s?e?n?t? ?b?y? ?t?h?e? ?m?a?i?l? ?t?r?a?n?s?f?e?r? ?a?g?e?n?t? ?t?o? ?t?h?e? ?s?e?n?d?e?r? ?s?t?a?t?i?n?g? ?t?h?a?t? ?t?h?e? ?s?e?n?d?e?r? ?h?a?s? ?n?o?t? ?y?e?t? ?b?e?e?n? ?w?e?l?c?o?m?e?d? ?b?y? ?t?h?a?t? ?p?a?r?t?i?c?u?l?a?r? ?r?e?c?i?p?i?e?n?t?.? ? ?T?h?i?s? ?a?v?o?i?d?s? ?c?o?n?f?i?r?m?a?t?i?o?n? ?o?f? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?e?x?i?s?t?e?n?c?e?,? ?p?r?o?t?e?c?t?i?o?n? ?a?g?a?i?n?s?t? ?s?p?a?m? ?f?l?o?o?d?i?n?g? ?a?n?d? ?m?u?l?t?i?p?l?e? ?u?n?w?a?n?t?e?d? ?r?e?q?u?e?s?t?s?,? ?a?n?d? ?i?n?e?f?f?i?c?i?e?n?t? ?u?s?e? ?o?f? ?b?a?n?d?w?i?d?t?h? ?b?e?t?w?e?e?n? ?m?a?i?l? ?t?r?a?n?s?f?e?r? ?a?g?e?n?t?s?.?
?
? ? ? ?I?f?,? ?u?p?o?n? ?r?e?c?e?i?p?t? ?o?f? ?a?n? ?e?m?a?i?l?,? ?t?h?e? ?e?-?m?a?i?l?? s? ?s?e?n?d?e?r?/?s?e?r?v?e?r? ?c?o?m?b?i?n?a?t?i?o?n? ?i?s? ?f?o?u?n?d? ?i?n? ?b?o?t?h? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?P?e?n?d?i?n?g? ?a?n?d? ?W?e?l?c?o?m?e? ?l?i?s?t?s?,? ?t?h?e? ?S?M?T?P?-?I?n?-?R?e?p?l?y?-?T?o? ?h?e?a?d?e?r? ?o?r? ?<?o?r?i?g?-?m?s?g?-?i?d?>? ?(?i?f? ?p?r?e?s?e?n?t?)? ?i?s? ?c?o?m?p?a?r?e?d? ?a?g?a?i?n?s?t? ?t?h?e? ?<?o?r?i?g?-?m?s?g?-?i?d?>? ?h?e?l?d? ?i?n? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?P?e?n?d?i?n?g? ?l?i?s?t?.? ? ?I?f? ?t?h?i?s? ?m?a?t?c?h?e?s?,? ?c?o?n?f?i?r?m?i?n?g? ?t?h?a?t? ?t?h?e? ?s?e?n?d?e?r? ?i?s? ?r?e?p?l?y?i?n?g? ?t?o? ?a? ?m?e?s?s?a?g?e? ?o?r?i?g?i?n?a?t?i?n?g? ?f?r?o?m? ?t?h?e? ?r?e?c?i?p?i?e?n?t?,? ?t?h?e? ?s?e?n?d?e?r?/?s?e?r?v?e?r? ?(?f?r?o?m? ?t?h?e? ?<?o?r?i?g?-?s?e?r?v?e?r?>? ?o?r? ?R?e?p?l?y?-?P?a?t?h? ?h?e?a?d?e?r?)?,? ?a?l?o?n?g? ?w?i?t?h? ?t?h?e? ?<?o?r?i?g?-?m?s?g?-?i?d?>? ?(?i?f? ?p?r?e?s?e?n?t?)? ?o?r? ?S?M?T?P?-?M?e?s?s?a?g?e?-?I?D? ?i?s? ?a?d?d?e?d? ?t?o? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?W?e?l?c?o?m?e? ?l?i?s?t? ?a?n?d? ?i?s? ?r?e?m?o?v?e?d? ?f?r?o?m? ?t?h?e? ?P?e?n?d?i?n?g? ?l?i?s?t? ?a?u?t?o?m?a?t?i?c?a?l?l?y?.?
?
? ? ? ?I?f? ?t?h?e? ?s?e?n?d?e?r?/?s?e?r?v?e?r? ?c?o?m?b?i?n?a?t?i?o?n? ?i?s? ?f?o?u?n?d? ?i?n? ?b?o?t?h? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?P?e?n?d?i?n?g? ?a?n?d? ?W?e?l?c?o?m?e? ?l?i?s?t?s?,? ?b?u?t? ?t?h?e? ?<?o?r?i?g?-?m?s?g?-?i?d?>? ?h?e?a?d?e?r? ?i?s? ?n?o?t? ?p?r?e?s?e?n?t? ?o?r? ?d?o?e?s? ?n?o?t? ?m?a?t?c?h? ?a?n?d? ?t?h?e? ?S?M?T?P? ?I?n?-?R?e?p?l?y?-?T?o? ?h?e?a?d?e?r? ?d?o?e?s? ?n?o?t? ?m?a?t?c?h? ?(?a?s? ?w?o?u?l?d? ?h?a?p?p?e?n? ?i?n? ?t?h?e? ?c?a?s?e? ?o?f? ?a?n? ?i?n?i?t?i?a?l? ?e?m?a?i?l? ?f?r?o?m? ?a? ?W?C?-?I?I? ?M?T?A? ?t?o? ?a? ?W?C?-?I? ?M?T?A?,? ?a?n?d? ?a? ?r?e?p?l?y? ?f?r?o?m? ?t?h?e? ?W?C?-?I? ?M?T?A? ?b?a?c?k? ?t?o? ?t?h?e? ?W?C?-?I?I? ?M?T?A?)?,? ?a? ?R?e?p?l?y?-?C?o?n?f?i?r?m?a?t?i?o?n?-?R?e?q?u?e?s?t? ?i?s? ?p?r?e?s?e?n?t?e?d? ?t?o? ?t?h?e? ?r?e?c?i?p?i?e?n?t?,? ?i?n? ?a? ?f?o?r?m?a?t? ?a?p?p?r?o?p?r?i?a?t?e? ?f?o?r? ?t?h?e? ?i?n?t?e?r?f?a?c?e? ?o?f? ?t?h?e? ?m?a?i?l? ?c?l?i?e?n?t?,? ?t?o? ?a?l?l?o?w? ?t?h?e? ?r?e?c?i?p?i?e?n?t? ?t?o? ?c?o?n?f?i?r?m? ?t?h?a?t? ?t?h?i?s? ?i?s? ?a? ?m?e?s?s?a?g?e? ?f?r?o?m? ?a? ?s?e?n?d?e?r? ?t?h?e? ?r?e?c?i?p?i?e?n?t? ?h?a?s? ?a?t? ?s?o?m?e? ?p?o?i?n?t? ?s?e?n?t? ?a? ?m?e?s?s?a?g?e? ?t?o?.? ? ?I?f? ?c?o?n?f?i?r?m?e?d?,? ?t?h?e? ?s?e?n?d?e?r? ?i?s? ?a?d?d?e?d? ?t?o? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?W?e?l?c?o?m?e?d? ?l?i?s?t? ?a?n?d? ?r?e?m?o?v?e?d? ?f?r?o?m? ?t?h?e?i?r? ?P?e?n?d?i?n?g? ?l?i?s?t?.? ? ?I?f? ?t?h?i?s? ?c?a?n?'?t? ?b?e? ?c?o?n?f?i?r?m?e?d?,? ?t?h?e? ?s?e?n?d?e?r? ?i?s? ?c?o?n?s?i?d?e?r?e?d? ?a? ?N?e?w? ?C?o?r?r?e?s?p?o?n?d?e?n?t?,? ?a?n?d? ?t?h?e? ?r?e?c?i?p?i?e?n?t? ?i?s? ?p?r?e?s?e?n?t?e?d? ?w?i?t?h? ?a? ?c?h?o?i?c?e? ?o?f? ?a?c?t?i?o?n?s?,? ?A?l?l?o?w?/?B?l?o?c?k?/?H?o?l?d? ?P?e?n?d?i?n?g?.?
?
? ? ? ?I?f? ?a? ?N?e?w? ?C?o?r?r?e?s?p?o?n?d?e?n?t? ?i?s? ?w?e?l?c?o?m?e?d? ?b?y? ?a? ?W?C?-?I?I? ?c?o?m?p?l?i?a?n?t? ?r?e?c?i?p?i?e?n?t?,? ?a?n?d? ?t?h?e? ?s?e?n?d?e?r?'?s? ?e?m?a?i?l? ?c?o?n?t?a?i?n?s? ?a?n? ?<?o?r?i?g?-?m?s?g?-?i?d?>? ?h?e?a?d?e?r?,? ?(?i?n?d?i?c?a?t?i?n?g? ?t?h?e? ?s?e?n?d?e?r? ?i?s? ?u?s?i?n?g? ?a? ?W?C?-?I?I? ?c?o?m?p?l?i?a?n?t? ?s?e?r?v?e?r?)? ?a?n? ?A?c?c?e?p?t?a?n?c?e? ?r?e?p?l?y? ?i?s? ?s?e?n?t? ?t?o? ?t?h?e? ?s?e?n?d?e?r?'?s? ?O?r?i?g?i?n?a?t?i?n?g?-?S?e?r?v?e?r? ?i?n?d?i?c?a?t?i?n?g? ?t?h?a?t? ?t?h?e? ?s?e?n?d?e?r? ?(?i?d?e?n?t?i?f?i?e?d? ?b?y? ?t?h?e? ?s?e?n?d?e?r?'?s? ?e?m?a?i?l? ?a?d?d?r?e?s?s?)? ?h?a?s? ?b?e?e?n? ?a?c?c?e?p?t?e?d? ?i?n?t?o? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?W?e?l?c?o?m?e? ?l?i?s?t? ?(?i?n?d?i?c?a?t?e?d? ?b?y? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?e?m?a?i?l? ?a?d?d?r?e?s?s? ?a?n?d? ?c?o?n?f?i?r?m?e?d? ?b?y? ?t?h?e? ?s?e?n?d?e?r?'?s? ?<?o?r?i?g?-?m?s?g?-?i?d?>?)?.? ? ?T?h?i?s? ?i?s? ?d?o?n?e? ?a?u?t?o?m?a?t?i?c?a?l?l?y? ?(?a?n?d? ?s?i?l?e?n?t?l?y?)? ?b?y? ?t?h?e? ?w?e?l?c?o?m?i?n?g? ?r?e?c?i?p?i?e?n?t?'?s? ?W?C?-?I?I? ?c?o?m?p?l?i?a?n?t? ?m?a?i?l? ?c?l?i?e?n?t?,? ?t?h?u?s? ?a?u?t?o?m?a?t?i?n?g? ?t?h?e? ?a?c?c?e?p?t?a?n?c?e? ?p?r?o?c?e?s?s? ?a?n?d? ?a?l?e?r?t?i?n?g? ?t?h?e? ?s?e?n?d?e?r? ?t?h?a?t? ?t?h?e?y? ?a?r?e? ?a? ?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?t?.? ? ?I?f? ?t?h?i?s? ?i?s? ?n?o?t? ?d?o?n?e? ?a?u?t?o?m?a?t?i?c?a?l?l?y? ?o?r? ?s?e?n?t? ?s?u?c?c?e?s?s?f?u?l?l?y?,? ?t?h?e? ?s?e?n?d?e?r? ?i?s? ?u?n?a?b?l?e? ?t?o? ?s?e?n?d? ?f?u?r?t?h?e?r? ?m?e?s?s?a?g?e?s?,? ?e?v?e?n? ?t?h?o?u?g?h? ?t?h?e? ?r?e?c?i?p?i?e?n?t? ?h?a?s? ?w?e?l?c?o?m?e?d? ?t?h?e?m?,? ?u?n?t?i?l? ?t?h?e? ?r?e?c?i?p?i?e?n?t? ?r?e?p?l?i?e?s?,? ?t?h?u?s? ?t?r?i?g?g?e?r?i?n?g? ?t?h?e? ?s?e?n?d?e?r?'?s? ?d?e?l?i?v?e?r?y? ?s?e?r?v?e?r? ?t?o? ?m?a?t?c?h? ?t?h?e? ?r?e?c?i?p?i?e?n?t?'?s? ?s?e?n?d?e?r?/?s?e?r?v?e?r? ?a?d?d?r?e?s?s?e?s? ?a?n?d? ?m?o?v?e? ?t?h?e?m? ?f?r?o?m? ?t?h?e? ?P?e?n?d?i?n?g? ?l?i?s?t? ?t?o? ?t?h?e? ?W?e?l?c?o?m?e?d? ?l?i?s?t?.? ? ?W?C?-?I?I? ?c?o?m?p?l?i?a?n?t? ?m?a?i?l? ?d?e?l?i?v?e?r?y? ?s?e?r?v?e?r?s? ?M?U?S?T? ?p?r?o?c?e?s?s? ?b?o?u?n?c?e? ?m?e?s?s?a?g?e?s? ?f?r?o?m? ?u?n?s?u?c?c?e?s?s?f?u?l? ?a?c?k?n?o?w?l?e?d?g?e?m?e?n?t?s? ?b?y? ?r?e?-?s?e?n?d?i?n?g? ?t?h?e? ?A?c?c?e?p?t?a?n?c?e? ?m?e?s?s?a?g?e?s? ?o?r? ?a?l?e?r?t?i?n?g? ?t?h?e? ?u?s?e?r?.?
?
?
?+?-?-?-?+? ?N?e?w? ?E?m?a?i?l?:?
?|? ? ? ?|? ?T?o?:? ?r?e?c?i?p?i?e?n?t?@?i?n?c?o?m?i?n?g?.?c?o?m?
?+?-?-?-?+? ?F?r?o?m?:? ?s?e?n?d?e?r?@?o?u?t?g?o?i?n?g?.?n?e?t?
? ? ?|?
? ? ?|? ? ?1? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?M?s?g?-?i?d?:? ?1?2?3?4?5?6?7? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ?\?|?/? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O?r?i?g?i?n?a?t?i?n?g? ?S?e?r?v?e?r?:?
?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ? ? ? ?s?m?t?p?.?o?u?t?g?o?i?n?g?.?n?e?t? ? ? ? ?3? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+?
?|?O?u?t?g?o?i?n?g? ?M?T?A? ?(?W?C?-?I?I?)?|?-?>?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?>?|?I?n?c?o?m?i?n?g? ?M?T?A? ?(?W?C?-?I?I?)?|?
?|? ? ?s?m?t?p?.?o?u?t?g?o?i?n?g?.?n?e?t? ?|?<?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?<?-?|? ? ?s?m?t?p?.?i?n?c?o?m?i?n?g?.?c?o?m? ?|?-?>?-?-?-?-?-?-?-?-?+?
?üÿ+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ?A?c?c?e?p?t?e?d? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1?0? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ? ? ? ? ? ? ? ? ? ?|?
? ? ?|? ? ? ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ?I?n?-?R?e?p?l?y?-?T?o?:? ?1?2?3?4?5?6?7? ? ? ? ? ? ? ? ? ? ? ? ?|? ?5? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|?
? ? ?|? ? ? ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O?r?i?g?i?n?a?t?i?n?g? ?S?e?r?v?e?r?:? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|?
? ? ?|? ? ? ?1?1? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?s?m?t?p?.?i?n?c?o?m?i?n?g?.?c?o?m? ? ? ? ? ? ? ? ? ? ? ?\?|?/? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|?
? ? ?|? ? ? ? ? ? ?|? ?R?e?p?l?y?-?T?o?:? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ? ? ? ? ?|? ?4?
? ? ?|? ? ? ? ? ? ?|? ? ? ? ?r?e?c?i?p?i?e?n?t?@?i?n?c?o?m?i?n?g?.?c?o?m? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|?I?n?c?o?m?i?n?g? ?d?e?l?i?v?e?r?y? ?(?W?C?-?I?I?)?|? ? ? ? ? ?|?
? ? ?|? ?2? ? ? ? ?|? ?O?r?i?g?i?n?a?t?i?n?g? ?S?e?r?v?e?r?:? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ?p?o?p?-?i?m?a?p?.?i?n?c?o?m?i?n?g?.?c?o?m? ? ?|?-?>?+? ? ?|?
? ? ?|? ? ? ? ? ? ?|? ? ? ? ?s?m?t?p?.?i?n?c?o?m?i?n?g?.?c?o?m? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ? ?|? ? ?|?
? ? ?|? ? ? ? ? ? ?|? ?o?r?i?g?-?m?s?g?-?i?d?:? ?1?2?3?4?5?6?7? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ? ? ? ? ? ?^? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ?|?
? ? ?|? ? ? ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ?6? ? ? ? ? ?|? ?7? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ?|?
? ? ?|? ? ? ? ? ?\?|?/? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ? ? ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ?|?
? ? ?|? ? ? ?+?-?-?-?-?-?-?-?+? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\?|?/? ? ? ? ? ? ?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?8? ?|? ? ?|?
? ? ?+?-?-?>?|?W?e?l?c?o?m?e?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ? ? ? ? ?|? ? ?|?
? ? ?|? ? ? ?+?-?-?-?-?-?-?-?+? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ?E?m?a?i?l? ?c?l?i?e?n?t? ?(?W?C?-?I?I?)? ?|? ? ? ? ? ?|? ? ?|?
? ? ?|? ? ? ?+?-?-?-?-?-?-?-?-?-?+? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|?r?e?c?i?p?i?e?n?t?@?i?n?c?o?m?i?n?g?.?c?o?m?|? ? ? ? ? ?|? ? ?|?
? ? ?+?-?-?>?|?U?n?w?e?l?c?o?m?e?|? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?+? ? ? ? ? ?|? ? ?|?
? ? ?|? ? ? ?+?-?-?-?-?-?-?-?-?-?+? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|? ? ?|?
? ? ?|? ? ? ?+?-?-?-?-?-?-?-?+? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ? ? ? ? ?|? ? ?|?
? ? ?+?-?-?>?|?P?e?n?d?i?n?g?|?-?-?-?-?-?-?-?>? ?(?T?r?a?s?h?)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|?W?e?l?c?o?m?e?|?<?-?-?-?-?+? ? ?|?
? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ? ? ?1?2? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ? ? ? ? ?|? ? ?|?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?-?+? ? ? ? ? ?|? ? ?|?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|?U?n?w?e?l?c?o?m?e?|?<?-?-?-?-?+? ? ?|?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?-?-?+? ? ? ? ? ? ? ? ?|?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+? ? ? ? ? ? ? ? ?|?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(?T?r?a?s?h?)?<?-?-?<?-?|?P?e?n?d?i?n?g?|?<?-?-?-?-?-?-?-?+?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+?-?-?-?-?-?-?-?+?
?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?F?r?o?m?:? ?s?e?n?d?e?r?@?o?u?t?g?o?i?n?g?.?n?e?t?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?o?r?i?g?-?m?s?g?-?i?d?:? ?1?2?3?4?5?6?7?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?O?r?i?g?i?n?a?t?i?n?g? ?s?e?r?v?e?r?:? ?s?m?t?p?.?o?u?t?g?o?i?n?g?.?n?e?t?
?
?F?i?g?u?r?e? ?3?:? ?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?P?h?a?s?e? ?I?I?
?
?
? ? ? ?I?n? ?o?r?d?e?r? ?t?o? ?m?a?i?n?t?a?i?n? ?W?e?l?c?o?m?e? ?a?n?d? ?U?n?w?e?l?c?o?m?e? ?l?i?s?t?s?,? ?W?C?-?I? ?a?n?d? ?W?C?-?I?I? ?d?e?l?i?v?e?r?y? ?s?e?r?v?e?r?s? ?M?U?S?T? ?p?r?o?v?i?d?e? ?a? ?l?i?s?t? ?o?f? ?W?e?l?c?o?m?e? ?a?n?d? ?U?n?w?e?l?c?o?m?e? ?u?s?e?r?s?.? ? ?T?h?i?s? ?i?s? ?p?r?e?s?e?n?t?e?d? ?i?n? ?e?i?t?h?e?r? ?a? ?W?C?-?I? ?c?o?m?p?a?t?i?b?l?e? ?e?m?a?i?l? ?a?s? ?d?e?s?c?r?i?b?e?d? ?a?b?o?v?e?,? ?o?r? ?i?n? ?a? ?f?o?r?m?a?t? ?a?p?p?l?i?c?a?b?l?e? ?t?o? ?t?h?e? ?W?C?-?I?I? ?c?l?i?e?n?t?'?s? ?i?n?t?e?r?f?a?c?e?.? ? ?I?t? ?i?s? ?R?E?C?O?M?M?E?N?D?E?D? ?t?h?a?t? ?U?n?w?e?l?c?o?m?e? ?l?i?s?t?s? ?c?o?n?t?a?i?n? ?t?h?e? ?s?u?b?j?e?c?t? ?l?i?n?e? ?o?f? ?t?h?e? ?i?n?i?t?i?a?l? ?e?m?a?i?l? ?f?r?o?m? ?t?h?e? ?u?n?w?e?l?c?o?m?e? ?s?e?n?d?e?r?,? ?a?s? ?a? ?r?e?m?i?n?d?e?r? ?t?o? ?t?h?e? ?r?e?c?i?p?i?e?n?t?.? ? ?P?e?n?d?i?n?g? ?l?i?s?t?s? ?M?U?S?T? ?p?r?o?v?i?d?e? ?t?h?i?s?.?
?
?
?1?.?3? ?M?o?v?i?n?g? ?t?o? ?a? ?N?e?w? ?S?e?r?v?e?r?/?S?e?r?v?i?c?e?
?
? ? ? ?W?h?e?n? ?a? ?u?s?e?r? ?c?h?a?n?g?e?s? ?e?m?a?i?l? ?a?d?d?r?e?s?s?e?s?,? ?p?r?e?s?u?m?a?b?l?y? ?t?h?e? ?s?e?r?v?e?r? ?n?a?m?e? ?w?i?l?l? ?c?h?a?n?g?e? ?a?s? ?w?e?l?l?.? ? ?T?h?i?s? ?c?o?u?l?d? ?f?o?r?s?e?e?a?b?l?y? ?r?e?s?u?l?t? ?i?n? ?a?l?l? ?p?r?e?v?i?o?u?s?l?y? ?w?e?l?c?o?m?e? ?s?e?n?d?e?r?s? ?h?a?v?i?n?g? ?t?o? ?r?e?-?r?e?q?u?e?s?t? ?p?e?r?m?i?s?s?i?o?n? ?t?o? ?s?e?n?d?.?
?
? ? ? ?B?y? ?m?i?g?r?a?t?i?n?g? ?W?e?l?c?o?m?e?/?U?n?w?e?l?c?o?m?e?/?P?e?n?d?i?n?g? ?l?i?s?t?s? ?b?e?t?w?e?e?n? ?o?l?d? ?a?n?d? ?n?e?w? ?s?e?r?v?e?r?s?,? ?a?n?d? ?a?l?e?r?t?i?n?g? ?e?x?i?s?t?i?n?g? ?w?e?l?c?o?m?e? ?s?e?n?d?e?r?s? ?f?r?o?m? ?t?h?e? ?n?e?w? ?a?d?d?r?e?s?s?,? ?t?h?e? ?e?m?a?i?l? ?a?d?d?r?e?s?s?e?e? ?i?s? ?a?b?l?e? ?t?o? ? ?k?e?e?p? ?t?h?e?i?r? ?w?h?i?t?e?/?b?l?a?c?k?l?i?s?t?s? ?u?p? ?t?o? ?d?a?t?e? ?w?i?t?h? ?a? ?s?i?m?p?l?e? ?o?n?e?-?t?i?m?e? ?o?p?e?r?a?t?i?o?n?.?
?
? ? ? ?A? ?W?C?-?I?I? ?c?o?m?p?l?i?a?n?t? ?e?m?a?i?l? ?c?l?i?e?n?t? ?c?a?n? ?i?s?s?u?e? ?a? ?r?e?q?u?e?s?t? ?t?o? ?l?i?s?t? ?a?l?l? ?w?e?l?c?o?m?e? ?a?n?d? ?u?n?w?e?l?c?o?m?e? ?s?e?n?d?e?r?s? ?f?r?o?m? ?t?h?e? ?o?l?d? ?s?e?r?v?i?c?e?,? ?a?d?d? ?t?h?e?m? ?t?o? ?t?h?e? ?l?i?s?t?s? ?o?n? ?t?h?e? ?n?e?w? ?s?e?r?v?i?c?e?,? ?a?n?d? ?t?h?e?n? ?i?s?s?u?e? ?a?n? ?u?p?d?a?t?e? ?t?o? ?t?h?e?s?e? ?n?e?w?l?y? ?a?d?d?e?d? ?s?e?n?d?e?r?s?.?
?
? ? ? ?T?h?e? ?u?p?d?a?t?e? ?w?i?l?l? ?a?l?t?e?r? ?t?h?e? ?W?e?l?c?o?m?e? ?l?i?s?t?s? ?o?f? ?t?h?e? ?s?e?n?d?e?r?s? ?b?y? ?c?h?a?n?g?i?n?g? ?t?h?e? ?e?m?a?i?l? ?a?d?d?r?e?s?s? ?a?n?d? ?<?o?r?i?g?-?s?e?r?v?e?r?>? ?f?i?e?l?d?s? ?m?a?t?c?h?i?n?g? ?t?h?e? ?u?s?e?r?s? ?o?l?d? ?e?m?a?i?l? ?a?d?d?r?e?s?s? ?a?n?d? ?<?o?r?i?g?-?m?s?g?-?i?d?>?.? ? ?A? ?n?e?w? ?<?o?r?i?g?-?m?s?g?-?i?d?>? ?w?i?l?l? ?b?e? ?p?u?t? ?i?n? ?p?l?a?c?e? ?o?f? ?t?h?e? ?e?x?i?s?t?i?n?g?,? ?u?s?i?n?g? ?a? ?s?e?r?v?e?r?-?g?e?n?e?r?a?t?e?d? ?s?t?r?i?n?g?.?
?
?
?2?.? ?F?u?l?l? ?C?o?p?y?r?i?g?h?t? ?S?t?a?t?e?m?e?n?t?
?? ? ? ?C?o?p?y?r?i?g?h?t? ?(?C?)? ?T?h?e? ?I?n?t?e?r?n?e?t? ?S?o?c?i?e?t?y? ?(?2?0?0?5?)?.?? ? ? ?? ? ? ?T?h?i?s? ?d?o?c?u?m?e?n?t? ?i?s? ?s?u?b?j?e?c?t? ?t?o? ?t?h?e? ?r?i?g?h?t?s?,? ?l?i?c?e?n?s?e?s? ?a?n?d? ?r?e?s?t?r?i?c?t?i?o?n?s? ?c?o?n?t?a?i?n?e?d? ?i?n? ?B?C?P? ?7?8?,? ?a?n?d? ?e?x?c?e?p?t? ?a?s? ?s?e?t? ?f?o?r?t?h? ?t?h?e?r?e?i?n?,? ?t?h?e? ?a?u?t?h?o?r? ?r?e?t?a?i?n?s? ?a?l?l? ?h?i?s? ?r?i?g?h?t?s?.?? ? ? ?? ? ? ?T?h?i?s? ?d?o?c?u?m?e?n?t? ?a?n?d? ?t?h?e? ?i?n?f?o?r?m?a?t?i?o?n? ?c?o?n?t?a?i?n?e?d? ?h?e?r?e?i?n? ?a?r?e? ?p?r?o?v?i?d?e?d? ?o?n? ?a?n? ?"?A?S? ?I?S?"? ?b?a?s?i?s? ?a?n?d? ?T?H?E? ?C?O?N?T?R?I?B?U?T?O?R?,? ?T?H?E? ?O?R?G?A?N?I?Z?A?T?I?O?N? ?H?E?/?S?H?E? ?R?E?P?R?E?S?E?N?T?S? ?O?R? ?I?S? ?S?P?O?N?S?O?R?E?D? ?B?Y? ?(?I?F? ?A?N?Y?)?,? ?T?H?E? ?I?N?T?E?R?N?E?T? ?S?O?C?I?E?T?Y? ?A?N?D? ?T?H?E? ?I?N?T?E?R?N?E?T? ?E?N?G?I?N?E?E?R?I?N?G? ?T?A?S?K? ?F?O?R?C?E? ?D?I?S?C?L?A?I?M? ?A?L?L? ?W?A?R?R?A?N?T?I?E?S?,? ?E?X?P?R?E?S?S? ?O?R? ?I?M?P?L?I?E?D?,? ?I?N?C?L?U?D?I?N?G? ?B?U?T? ?N?O?T? ?L?I?M?I?T?E?D? ?T?O? ?A?N?Y? ?W?A?R?R?A?N?T?Y? ?T?H?A?T? ?T?H?E? ?U?S?E? ?O?F? ?T?H?E? ?I?N?F?O?R?M?A?T?I?O?N? ?H?E?R?E?I?N? ?W?I?L?L? ?N?O?T? ?I?N?F?R?I?N?G?E? ?A?N?Y? ?R?I?G?H?T?S? ?O?R? ?A?N?Y? ?I?M?P?L?I?E?D? ?W?A?R?R?A?N?T?I?E?S? ?O?F? ?M?E?R?C?H?A?N?T?A?B?I?L?I?T?Y? ?O?R? ?F?I?T?N?E?S?S? ?F?O?R? ?A? ?P?A?R?T?I?C?U?L?A?R? ?P?U?R?P?O?S?E?.?
?
?
?3?.? ?R?e?f?e?r?e?n?c?e?s?
?
? ? ? ?[?B?C?P?7?9?]? ?S?.? ?B?r?a?d?n?e?r?,? ?"?I?n?t?e?l?l?e?c?t?u?a?l? ?P?r?o?p?e?r?t?y? ?R?i?g?h?t?s? ?i?n? ?I?E?T?F? ?T?e?c?h?n?o?l?o?g?y?"?,? ?B?C?P? ?7?9?,? ?R?F?C? ?3?6?6?8?,? ?I?n?t?e?l?l?e?c?t?u?a?l? ?P?r?o?p?e?r?t?y? ?R?i?g?h?t?s? ?W?o?r?k?i?n?g?
?G?r?o?u?p? ?o?f? ?t?h?e? ?I?E?T?F?,? ?F?e?b?r?u?a?r?y? ?2?0?0?4? ?
?
? ? ? ?[?W?C?o?r?-?P?O?P?]? ?D?.? ?S?z?e?g?o?,? ?"?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?E?x?t?e?n?s?i?o?n?s? ?t?o? ?I?M?A?P?4?"?,? ?I?n?t?e?r?n?e?t? ?D?r?a?f?t? ?"?d?r?a?f?t?-?s?z?e?g?o?-?w?c?o?r?-?i?m?a?p?-?0?1?.?t?x?t?"?,? ?J?a?n?u?a?r?y? ?2?0?0?6?
?
? ? ? ?[?W?C?o?r?-?I?M?A?P?]? ?D?.? ?S?z?e?g?o?,? ?"?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?E?x?t?e?n?s?i?o?n?s? ?t?o? ?P?O?P?3?"?,? ?I?n?t?e?r?n?e?t? ?D?r?a?f?t? ?"?d?r?a?f?t?-?s?z?e?g?o?-?w?c?o?r?-?i?m?a?p?-?0?1?.?t?x?t?"?,? ?J?a?n?u?a?r?y? ?2?0?0?6?
?
? ? ? ?[?W?C?o?r?-?E?S?M?T?P?]? ?D?.? ?S?z?e?g?o?,? ?"?W?e?l?c?o?m?e?d? ?C?o?r?r?e?s?p?o?n?d?e?n?c?e? ?E?x?t?e?n?s?i?o?n?s? ?t?o? ?E?S?M?T?P?"?,? ?I?n?t?e?r?n?e?t? ?D?r?a?f?t? ?"?d?r?a?f?t?-?s?z?e?g?o?-?w?c?o?r?-?i?m?a?p?-?0?1?.?t?x?t?"?,? ?J?a?n?u?a?r?y? ?2?0?0?6?
?
?
?4?.? ?A?u?t?h?o?r?'?s? ?A?d?d?r?e?s?s?
?
? ? ? ?D?a?v?i?d? ?J?.? ?S?z?e?g?o?
? ? ? ?2?6? ?V?a?l?l?e?y?v?i?e?w? ?R?o?a?d?
? ? ? ?T?h?o?r?n?h?i?l?l?,? ?O?n?t?a?r?i?o?
? ? ? ?L?3?T? ?6?X?5? ?C?a?n?a?d?a?
?
? ? ? ?d?a?v?i?d?@?m?i?n?d?s?l?i?p?.?o?r?g?
?
?
?Internet-Draft D. Szego

Standards Track                         david@???
Document: draft-szego-wcor-pop-01.txt   January 2006

        Welcomed Correspondence Extensions
                to POP3

Network Working Group
Internet-Draft SubmissionCategory: 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, the 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 [BCP79]. 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@??? .
Distribution of this memo is unlimited.

Copyright (C) The Internet Society. 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 WCor/WC for short) extension to POP3. "Welcomed Correspondence" is explained in detail in Internet-Draft draft-szego-wcor-overview-01.txt [WCor-Overview]. This extension is based on the standard "POP3 Extension Mechanism" described in RFC 2449 [RFC2449]. Welcomed Correspondence capabilities are identified by the WCOR keyword (POP3 extensions disallow "X-" prefixes) in the POP3 capabilities list presented by a WC-Compliant POP3 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@???> (or <email@???>), <orig-msg-id>,  <orig-server>

The <email@???> 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 <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 <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 2449 [RFC2449] section 3, "General Command and Response Grammar".


2. WCOR Capability Extension Overview

The WCOR capability provides Welcomed Correspondence extensions to a POP3 server by allowing the POP3 server and client to interact directly with a user's Welcome, Unwelcome, and Pending lists. This extension MUST only be available in the TRANSACTION 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 POP server MUST have one set of lists. A WC-compliant POP 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@???>, <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@???>, <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@???>, <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 per RFC 2449 [RFC2449] as follows:

      WCOR capability

      CAPA tag:
         WCOR

      Arguments:
         none

      Added commands:
         LISTNEWREQ LISTPENDREQ ALLOW BLOCK LISTALLOWED LISTBLOCKED SENDUPDATE

      Standard commands affected:
         none

      Commands vaild in states:
         TRANSACTION

      Specification reference:
         This document, and Internet-Draft [WCor-Overview]

      Announced states / possible differences:
         both / 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

      SENDUPDATE
         Alert Welcome senders of address changes

These commands are described below.


3.1. Identification of a WC-Compliant Mail Client

Mail clients will identify themselves as WC-Compliant by issuing the WCOR command in the TRANSACTION state.

The server MUST reply with a proper POP3 "+OK" result if it is offering Welcomed Correspondence capabilities.

   Example:
      C: WCOR
      S: +OK

Failure of the WCOR command MUST result in a proper POP3 "-ERR" message. The text of the result SHOULD include a comment explaining why the command failed.

   Example:
      C: WCOR
      S: -ERR Authenticate first

      C: WCOR
      S: -ERR 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 POP3 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 POP3 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 POP3 "+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: LISTNEWREQ
      S: +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 POP3 server MUST respond with each entry on a separate line after the "+OK" reply. The list MUST be terminated with a single "." 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@???> <SP> <orig-server> <SP> <Receipt-Date> <SP> Subject to end of line <EOL>

   Example:
      C: LISTNEWREQ
      S: +OK You have 3 New Correspondence Requests:
      S: David Szego <dszego@???> smtp.mindslip.com 11022004-213233 Re: Your question
      S: John Doe <jdoe@???> mail.spam.com 12022004-094312 Buy Pharmaceuticals Online!
      S: spam@??? fake.spam.net 12022004-125326 E.n.l.a.r.g.e yourself
      S: .

Failure of the LISTNEWREQ command MUST result in a proper POP3 "-ERR" result. The text of the result SHOULD include a comment explaining why the command failed.

   Example:
      C: LISTNEWREQ
      S: -ERR 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 POP3 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 POP3 "+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: LISTPENDREQ
      S: +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 POP3 server MUST respond with each entry on a separate line after the "+OK" reply. The list MUST be terminated with a single "." 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@???> <SP> <orig-server> <SP> <Receipt-Date> <SP> Subject to end of line <EOL>

   Example:
      C: LISTPENDREQ
      S: +OK You have 3 pending Correspondence Requests:
      S: David Szego <dszego@???> smtp.mindslip.com 11022004-213233 Re: Your question
      S: John Doe <jdoe@???> mail.spam.com 12022004-094312 Buy Pharmaceuticals Online!
      S: spam@??? asdf.fake.net 12022004-125326 E.n.l.a.r.g.e yourself
      S: .

Failure of the LISTPENDREQ command MUST result in a proper POP3 "-ERR" result. The text of the result SHOULD include a comment explaining why the command failed.

   Example:
      C: LISTPENDREQ
      S: -ERR Cannot access WC lists at this time

3.4. The ALLOW Command

The ALLOW command tells the WC-Compliant POP3 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@???> <SP> <orig-server> <SP> <orig-msg-id>

   Example:
      ALLOW dszego@??? smtp.sender.net 1234567.98765432@???

Successful addition of this sender to a user's Welcome list MUST result in a proper POP3 "+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: ALLOW dszego@??? smtp.sender.net 1234567.98765432@???
      S: +OK dszego@??? 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: ALLOW *@mindslip.com mindslip.com 1234567.09876543@???
      S: +OK The domain mindslip.com is now allowed to send you email

Failure of the ALLOW command MUST result in a proper POP3 "-ERR" message. The text of the result SHOULD include a comment explaining why the command failed.

   Example:
      C: ALLOW dszego@??? smtp.sender.net 1234567.98765432@???
      S: -ERR 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 POP3 server to check for the presence of the sender's <email@???> / <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 POP3 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@???> <SP> <orig-server> (optional: <SP> <orig-msg-id>)

   Example:
      BLOCK spammer@??? 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 POP3 "+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: BLOCK spammer@??? smtp.spamco.com
      S: +OK spammer@??? is now blocked from sending you mail from smtp.spamco.com

Failure of the BLOCK command MUST result in a proper POP3 "-ERR" reply. The text of the result SHOULD include a comment explaining why the command failed.

   Example:
      C: BLOCK spammer@??? smtp.spamco.com
      S: -ERR 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 POP3 server to check for the presence of the sender's <email@???> / <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 POP3 server.

The LISTALLOWED command does not take any parameters.

This command MUST reply with a proper POP3 "+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: LISTALLOWED
      S: +OK There is nobody on your Welcome list

If there is one (1) or more entries in the Welcome list, the POP3 server MUST with each entry on a separate line after the "+OK" reply. The list MUST be terminated with a single "." on a final line by itself. Blank lines MUST NOT appear between list entries.

The format for the response is as follows:

      <email@???> <SP> <orig-server> <EOL>

   Example:
      C: LISTALLOWED
      S: +OK You have 1 people on your Welcome list
      S: David Szego <dszego@???> smtp.mindslip.com
      S: .

Failure of the LISTALLOWED command MUST result in a proper POP3 "-ERR" result. The text of the result SHOULD include a comment explaining why the command failed.

   Example:
      C: LISTALLOWED
      S: -ERR 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 POP3 server.

The LISTBLOCKED command does not take any parameters.

This command MUST reply with a proper POP3 "+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: LISTBLOCKED
      S: +OK There is nobody on your Unwelcome list

If there is one (1) or more entries in the Unwelcome list, the POP3 server MUST with each entry on a separate line after the "+OK" reply. The list MUST be terminated with a single "." 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@???> <SP> <orig-server> <SP> <Receipt-Date> <SP> Subject to end of line <EOL>

   Example:
      C: LISTBLOCKED
      S: +OK You have 1 sender on your Unwelcome list
      S: Joe Spammer <spam@???> mail.spam.com E.n.l.a.r.g.e yourself
      S: .

Failure of the LISTBLOCKED command MUST result in a proper POP3 "-ERR" result. The text of the result SHOULD include a comment explaining why the command failed.

   Example:
      C: LISTBLOCKED
      S: -ERR Cannot access WC lists at this time

4. Handling Email

WC-Compliant POP3 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 POP3 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 POP3 server has the WCor <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 POP3 server does not have the WC 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 POP3 servers MUST check all emails for the presence of the WC Headers. If present, and if the POP3 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 POP3 server implementation.


5. Handling Non-WC-Compliant Mail Clients: New Correspondence Requests

WC-Compliant mail clients MUST issue the WCOR command in the TRANSACTION state to identify themselves as WC-Compliant. If a mail client does not issue the WCOR command, a WC-Compliant POP3 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 POP3 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@???>
      Reply-To:   dszego@???
      To:         dszego@???
      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@???>
      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@???>
      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@???>
      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@???>
      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 POP3 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 POP3 server MUST keep track of it's generated UIDs in order to verify authenticity. The POP3 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 POP3 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 POP3 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 POP commands and one (1) new capability keyword as protocol extensions in compliance with RFC 2449 [RFC2449] section 9.

POP3 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently contained in RFC 2449 [RFC2449].

IANA is requested to add these POP3 commands and capability 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 (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the author retains all his 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

[RFC2449] R. Gellens, C. Newman, L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998

[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@???

Internet-Draft D. Szego

Standards Track                         david@???
Document: draft-szego-wcor-smtp-01.txt  June 2005

        Welcomed Correspondence Extensions
                to ESMTP

Network Working Group
Internet-Draft SubmissionCategory: 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, the 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 [BCP79]. 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@??? .
Distribution of this memo is unlimited.

Copyright (C) The Internet Society. 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-01.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@???
      S: 250 ok
      C: RCPT TO: recipient@???
      S: 250 ok
      C: DATA
      S: 354 send the mail data, end with .
      C: Date: 23 Oct 81 11:22:33
      C: From: SMTP@???
      C: To: JOE@???
      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 (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the author retains all his 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.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@???