Index: courier/doc/draft-varshavchik-exdata-smtpext.txt
===================================================================
RCS file: /cvsroot/courier/courier/courier/courier/doc/draft-varshavchik-exdata-smtpext.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- courier/doc/draft-varshavchik-exdata-smtpext.txt	11 May 2000 23:42:50 -0000	1.2
+++ courier/doc/draft-varshavchik-exdata-smtpext.txt	24 May 2008 01:47:35 -0000	1.3
@@ -4,44 +4,6 @@
 
 
 
-INTERNET-DRAFT                                            S. Varshavchik
-Expires XXX, XX XXXX                              Double Precision, Inc.
-                                                           July 26, 1999
-
-                        Extended SMTP DATA Reply
-                 draft-varshavchik-data-smtpext-03.txt
-
-Status Of This Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   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.
-
-0. Revision history
-
-   01 - fixed a footnote typo.  Added references to related documents:
-   RFC2033, RFC1047, draft-ietf-fax-smtp-session.
-
-   02 - incorporated several minor suggested clarifications.
-
-   03 - clarified the "opt-in" proposed compromise in section 8.1
-
 1. Abstract
 
    This document describes an extension to the SMTP service [RFC1425],
@@ -52,14 +14,6 @@
    desirable feature because of escalating amounts of unwanted junk E-
    mail sent over the Internet.
 
-
-
-
-Expires XXX XX, XXXX                                            [Page 1]
-
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
-
-
 2. Introduction
 
    The reply to the SMTP [RFC821] DATA verb is a status code indicating
@@ -98,6 +52,14 @@
            only on the network address and the return address is of very
            limited benefit.
 
+
+
+
+Expires XXX XX, XXXX                                            [Page 1]
+
+EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+
+
    There are several other mail enhancements that involve recipient-
    specific processing.  [RFC2033] defines a related, but a completely
    different, mail delivery protocol which features recipient-specific
@@ -108,14 +70,6 @@
 
 3. Framework for the EXDATA SMTP transport extension
 
-
-
-
-Expires XXX XX, XXXX                                            [Page 2]
-
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
-
-
    This SMTP transport extension [RFC1425] is laid out as follows.
 
       (1) The name of the SMTP transport extension defined here is
@@ -154,6 +108,14 @@
    command.
 
    An extended DATA verb reply MAY be sent instead of the second status
+
+
+
+Expires XXX XX, XXXX                                            [Page 2]
+
+EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+
+
    code reply to the DATA verb. It MUST NOT be sent as the first reply
    to the DATA verb (before the message is transmitted).  Using the
    extended format in the second reply to the DATA verb is optional, and
@@ -164,14 +126,6 @@
 
    The extended SMTP DATA reply uses the 558 numeric status code which
    is explicitly reserved for this purpose.  When a 558 numeric status
-
-
-
-Expires XXX XX, XXXX                                            [Page 3]
-
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
-
-
    code is the second reply to the DATA verb, the reply MUST be
    formatted as follows, where <SP>, <CR> and <LF> represent the ASCII
    space, carriage return, and line feed characters:
@@ -211,6 +165,13 @@
 
 6. Restrictions on the extended SMTP DATA reply
 
+
+
+Expires XXX XX, XXXX                                            [Page 3]
+
+EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+
+
    Extended replies MUST contain exactly one individual reply for each
    recipient whose RCPT TO command was acknowledged with a 2xx result
    code.  Extended replies MUST NOT have any replies for recipients
@@ -220,14 +181,6 @@
    For example, if a message had three recipients, and the second RCPT
    TO command was rejected, the extended reply MUST contain two
    individual replies: the first one is for the first recipient, the
-
-
-
-Expires XXX XX, XXXX                                            [Page 4]
-
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
-
-
    second one for the last recipient.
 
    Technically, an extended SMTP DATA reply with a 2xx numeric code in
@@ -268,6 +221,40 @@
    reply per recipient.  Each individual reply may be a multiline reply
    itself.
 
+
+
+Expires XXX XX, XXXX                                            [Page 4]
+
+EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+
+
+7.2 Parsing incomplete replies
+
+   If the client receives an incomplete 558 reply, the client should
+   process normally any of this replyâs subreplies which were received
+   in their entirety, and should process any incomplete or unreceived
+   subreplies as if they had been 451 subreplies.
+
+   While receiving a 558 reply, the client must implement a timeout of
+   at least 10 minutes per subreply.  It MUST use per- subreply timeouts
+   rather than trying to time the entire 558 reply.  This means that the
+   overall timeout is approximately proportional to the number of
+   recipients.
+
+   Rationale: The 10 minute limit is chosen because thatâs the suggested
+   minimum timeout for processing a message body, in the middle of
+   section 4.5.3.2 of RFC 2821.  The second and third sentences above
+   are adapted from the first paragraph of that same section of the RFC.
+
+   While sending a 558 reply, the server should take no more than about
+   5 minutes to send each subreply.  If individual users administer
+   their own filtering software, it would be advisable to use a timeout
+   mechanism to force a decision after 5 minutes.
+
+   Rationale: if a userâs filter always takes too long, and triggers the
+   clientâs 10 minute timeout, other users might not ever be able to
+   receive the message.
+
 8.  Security Concerns
 
 8.1 Transitional behavior
@@ -276,14 +263,6 @@
    individual mail filters to reject mail during an SMTP transaction.
    However this extension must be widely implemented for this to happen.
    Furthermore, the sending SMTP agent can always omit the EXDATA
-
-
-
-Expires XXX XX, XXXX                                            [Page 5]
-
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
-
-
    keyword from the MAIL FROM: verb.
 
    It follows that recipient-specific mail filtering is still a very
@@ -297,6 +276,14 @@
 
    Another possible approach is to go ahead and issue an extended reply,
    which will be interpreted as a permanent failure by the sending SMTP
+
+
+
+Expires XXX XX, XXXX                                            [Page 5]
+
+EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+
+
    agent.  This approach is usually unacceptable because the sending
    SMTP agent will correctly conclude that every recipient was
    undeliverable.  If a message comes from a mailing list, the mailing
@@ -304,7 +291,7 @@
    list only because of a malfunctioning mail filter used by one
    recipient only.
 
-   Here's an approach that attempts to achieve a compromise between
+   Hereâs an approach that attempts to achieve a compromise between
    having recipient-specific mail filtering, and avoiding unwanted
    disruptions of this kind.
 
@@ -332,14 +319,6 @@
            additional recipients MUST NOT have this message whitelisted
            If they do, reject the corresponding RCPT TO: verb with a
            temporary 421 status code.  The sending SMTP agent is
-
-
-
-Expires XXX XX, XXXX                                            [Page 6]
-
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
-
-
            expected to retransmit the message for all whitelisted
            recipients after a small delay.
 
@@ -348,11 +327,19 @@
            delay in between).  Individual recipients can decide whether
            to whitelist specific sources of mail (such as mailing
            lists).  By whitelisting known mail sources, the recipients
-           can make sure that anyone else's mail filter will not affect
+           can make sure that anyone elseâs mail filter will not affect
            their mail delivery.
 
 8.2 Response time to SMTP DATA
 
+
+
+
+Expires XXX XX, XXXX                                            [Page 6]
+
+EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+
+
    Implementations should try to avoid any lengthy delays due to mail
    filters being used, before returning a reply to the SMTP DATA.  Many
    SMTP clients wait for a response for only a short period of time,
@@ -388,40 +375,15 @@
            Carnegie Mellon, October 1996.
 
        [RFC1047] Partridge, C., "DUPLICATE MESSAGES AND SMTP", RFC 1047,
-
-
-
-Expires XXX XX, XXXX                                            [Page 7]
-
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
-
-
            CIC at BBN Labs, February 1988.
 
-11. Author's address
+11. Authorâs address
 
    Sam Varshavchik
    Double Precision, Inc.
-   PO Box 668
-   Greenwood Lake, NY 10925
-   <mrsam@geocities.com>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+   402 Main Street Suite 100-241
+   Metuchen, NJ 08840
+   <mrsam@courier-mta.com>
 
 
 
@@ -429,22 +391,4 @@
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires XXX XX, XXXX                                            [Page 8]
+Expires XXX XX, XXXX                                            [Page 7]
Index: courier/doc/draft-varshavchik-security-smtpext.txt
===================================================================
RCS file: /cvsroot/courier/courier/courier/courier/doc/draft-varshavchik-security-smtpext.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- courier/doc/draft-varshavchik-security-smtpext.txt	19 Apr 2001 02:58:43 -0000	1.2
+++ courier/doc/draft-varshavchik-security-smtpext.txt	24 May 2008 01:47:35 -0000	1.3
@@ -4,37 +4,6 @@
 
 
 
-INTERNET-DRAFT                                            S. Varshavchik
-Expires XXX XX, XXXX                              Double Precision, Inc.
-                                                            XXX XX, XXXX
-
-                    SECURITY SMTP Service Extension
-                 draft-varshavchik-security-smtpext.txt
-
-Status Of This Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   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.
-
-0. Revision history
-
 1. Abstract
 
    This document describes an [ESMTP] extension that enables the sender
@@ -52,14 +21,6 @@
    extension, but sometimes the sender might wish to require that
    [STARTTLS], or an equivalent, must be used to deliver a particular
    message.  Even if two mail nodes - the sending and the receiving
-
-
-
-S. Varshavchik            Expires XXX XX, XXXX                  [Page 1]
-
-SECURITY SMTP Extension      S. Varshavchik                 XXX XX, XXXX
-
-
    nodes - are set up to use [STARTTLS], there are known methods of
    attack - such as [DNS] cache poisoning - which can be used to
    intercept mail traffic.
@@ -91,6 +52,14 @@
    argument.  This document defines two words that may appear in the
    EHLO SECURITY list:
 
+
+
+
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 1]
+
+SECURITY SMTP Extension      S. Varshavchik                 XXX XX, XXXX
+
+
           NONE      - No security.
 
           STARTTLS  - Must use STARTTLS to deliver the message.
@@ -108,16 +77,8 @@
    SECURITY=STARTTLS specifies that the mail relay MUST use [STARTTLS]
    with a remote mail node.  The mail relay ignores this option if it
    delivers the message to a local mailbox.  The sending mail relay MUST
-
-
-
-S. Varshavchik            Expires XXX XX, XXXX                  [Page 2]
-
-SECURITY SMTP Extension      S. Varshavchik                 XXX XX, XXXX
-
-
    also verify the X.509 certificate received from the remote mail relay
-   during TLS negotiation.  The remote relay's X.509 certificate MUST be
+   during TLS negotiation.  The remote relayâs X.509 certificate MUST be
    signed by a certificate authority that is known and trusted by the
    sending relay.  If the remote relay does not support [STARTTLS], or
    is unable to provide a satisfactory X.509 certificate, the message
@@ -139,7 +100,7 @@
    the sender over the secure, internal, network.
 
    A mail relay MAY automatically "upgrade" the SECURITY level of a
-   message based on the mail relay's administrative policies.  A node
+   message based on the mail relayâs administrative policies.  A node
    MUST NOT automatically downgrade the SECURITY level.  For the purpose
    of determining the security level SECURITY=STARTTLS is considered to
    be more secure than SECURITY=NONE.  This allows the implementation of
@@ -147,6 +108,14 @@
    untrusted network, without any modification to existing mail user
    agents.
 
+
+
+
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 2]
+
+SECURITY SMTP Extension      S. Varshavchik                 XXX XX, XXXX
+
+
 5. Example
 
        220 example.com ESMTP
@@ -155,7 +124,7 @@
        250 STARTTLS
        STARTTLS
        220 Go ahead.
-       _(_T_L_S _n_e_g_o_t_i_a_t_i_o_n _t_a_k_e_s _p_l_a_c_e_)
+       [4m(TLS[24m [4mnegotiation[24m [4mtakes[24m [4mplace)[0m
        EHLO domain.com
        250-example.com ESMTP
        250-SECURITY=NONE,STARTTLS
@@ -164,15 +133,7 @@
        250 HELP
        MAIL FROM:<itny-out@domain.com> SIZE=1250 SECURITY=STARTTLS
        250 Ok
-
-
-
-S. Varshavchik            Expires XXX XX, XXXX                  [Page 3]
-
-SECURITY SMTP Extension      S. Varshavchik                 XXX XX, XXXX
-
-
-       _(_N_o_r_m_a_l _S_M_T_P _d_i_a_l_o_g_u_e _c_o_n_t_i_n_u_e_s_._._._)
+       [4m(Normal[24m [4mSMTP[24m [4mdialogue[24m [4mcontinues...)[0m
 
 6. Delivery Status Notifications
 
@@ -193,7 +154,7 @@
    a secure mail transmission infrastructure between trusted hosts over
    a public, untrusted, network.  This is done by installing X.509
    certificates signed by a trusted certificate authority, then using
-   SECURITY to require [STARTTLS] (or configuring the mail relay's
+   SECURITY to require [STARTTLS] (or configuring the mail relayâs
    configuration to automatically upgrade SECURITY for outgoing
    messages).
 
@@ -203,15 +164,23 @@
    or [DNS] cache poisoning, can be used to redirect mail to a node with
    a valid certificate signed by a public CA.
 
+
+
+
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 3]
+
+SECURITY SMTP Extension      S. Varshavchik                 XXX XX, XXXX
+
+
    Note that a trusted mail node CAN use DNS cache poisoning to
    intercept mail addressed to another trusted mail node, since the
    attacker will have a certificate signed by the private CA.  It is
    important to understand that the SECURITY extension is designed to
    defend against attacks from untrusted mail nodes only.
 
-   The SECURITY extension's scope is limited to delivery of a message to
-   the recipient's mailbox.  Once a message is delivered, it is the
-   recipient's responsibility to access the message in a secure
+   The SECURITY extensionâs scope is limited to delivery of a message to
+   the recipientâs mailbox.  Once a message is delivered, it is the
+   recipientâs responsibility to access the message in a secure
    environment, such as by using SSL/TLS-wrapped versions of existing
    mailbox access protocols.
 
@@ -220,14 +189,6 @@
    [ESMTP]    Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker,
               D.  "SMTP Service Extensions", RFC 1425, United Nations
               University, Innosoft International, Inc., Dover Beach
-
-
-
-S. Varshavchik            Expires XXX XX, XXXX                  [Page 4]
-
-SECURITY SMTP Extension      S. Varshavchik                 XXX XX, XXXX
-
-
               Consulting, Inc., Network Management Associates, Inc., The
               Branch Office, February 1993
 
@@ -241,21 +202,13 @@
    [DNS]      Mockapetris, P., "Domain Names - Implementation and
               Specification", RFC 1035, ISI, November 1987
 
-9. Author's address
+9. Authorâs address
 
    Sam Varshavchik
    Double Precision, Inc.
-   PO Box 668
-   Greenwood Lake, NY 10925
-   <sam@courier-mta.com>
-
-
-
-
-
-
-
-
+   402 Main Street Suite 100-241
+   Metuchen, NJ 08840
+   <mrsam@courier-mta.com>
 
 
 
@@ -270,13 +223,4 @@
 
 
 
-
-
-
-
-
-
-
-
-
-S. Varshavchik            Expires XXX XX, XXXX                  [Page 5]
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 4]
Index: courier/doc/draft-varshavchik-verp-smtpext.txt
===================================================================
RCS file: /cvsroot/courier/courier/courier/courier/doc/draft-varshavchik-verp-smtpext.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- courier/doc/draft-varshavchik-verp-smtpext.txt	3 Apr 2005 16:22:06 -0000	1.5
+++ courier/doc/draft-varshavchik-verp-smtpext.txt	24 May 2008 01:47:35 -0000	1.6
@@ -4,433 +4,597 @@
 
 
 
-INTERNET-DRAFT                                            S. Varshavchik
-Expires XXX, XX XXXX                              Double Precision, Inc.
-                                                       February 13, 2005
+1. Abstract
 
-                        Extended SMTP DATA Reply
-                 draft-varshavchik-data-smtpext-03.txt
+   This document describes an extension to the SMTP service [1], called
+   Variable Envelope Return Path (VERP).  The VERP extension implements
+   a way of automatically identifying undeliverable mail recipients,
+   even when non-delivery reports originate from mail systems that do
+   not implement delivery status notifications, as specified in [2] and
+   [3].
 
-Status Of This Memo
+2. Introduction
 
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
+   All E-mail software can expect to deal with undeliverable mail.  [2]
+   and [3] specify a machine-readable format for delivery status
+   notifications (DSNs, or non-delivery reports).  DSNs allow
+   undeliverable mail to be handled in a totally automatic fashion,
+   without requiring manual intervention.  For example, mailing list
+   managers can automatically identify addresses that are no longer
+   deliverable, and remove them from the mailing list.
+
+   Although [2] and [3] are now widely implemented, there are still many
+   systems that do not use them.  This makes it impractical to
+   completely rely on DSNs for automatic mailing list management.
+   Undeliverable addresses accumulate quickly even from a very small
+   percentage of non-DSN systems.  This results in a non-trivial amount
+   of manual work to identify undeliverable addresses and purge them
+   from the mailing list.
+
+   Mailing list software began to use VERPs (the acronym stands for
+   Variable Envelope Return Path) after DSNs were found to be
+   impractical for totally automatic mailing list management.  VERPs are
+   an alternative way to handle non-delivery notices.  The advantage of
+   VERPs is that they can be made to work automatically, even when non-
+   delivery notices are not in the format specified by [2].
+
+   Unfortunately, VERPs require much more bandwidth and network
+   resources than DSNs because VERPs cannot be used to send one copy of
+   a mailing list message addressed to all the recipients in the same E-
+   mail domain.
+
+   This SMTP service extension allows E-mail software to send a single
+   VERP message to all addresses in the same mail domain, for as long as
+   mail servers, which relay the message, support the VERP SMTP
+   extension.
+
+   The VERP message may be eventually relayed to a mail server that does
+   not support this extension.  Separate messages - with variable
+   envelope return paths - will be sent when this happens.
 
-   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
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 1]
+
+VERP SMTP Extension          S. Varshavchik                 XXX XX, XXXX
 
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
 
-0. Revision history
+   So the worst case scenario results in the same situation where
+   traditional VERPs are used right from the start.  The best case
+   scenario results in significant savings of network resources and
+   bandwidth, from eliminating hundreds (or more) copies of the same
+   message.
+
+   Essentially, the VERP extension postpones the generation of multiple
+   messages with different return paths as much as possible, until it is
+   absolutely required.
+
+2.1 VERP overview
+
+   The traditional VERP message encodes the recipient address as a
+   portion of the return address.  When undeliverable mail comes back,
+   the mail software decodes the return address (now the recipient
+   address) and obtains the address responsible for the non-delivery
+   notice.
+
+   For example: mail sent by a mailing list manager to the address
+   <john@example.org> carries a return address of <mlist-return-
+   john=example.org@domain.com>.  The mailing list software at
+   domain.com handles all mail with the local portion of the address
+   starting with "mlist-return-".  If a non-delivery notice is generated
+   because the address is not deliverable, the mailing list software
+   takes the address where the non-delivery report was sent, retrieves
+   the remaining portion of the local address, "john=example.org", and
+   determines that the undeliverable address was <john@example.org>.
 
-   01 - fixed a footnote typo.  Added references to related documents:
-   RFC2033, RFC1047, draft-ietf-fax-smtp-session.
+   This does not rely on RFC 1894, and will work for all non-delivery
+   notices.
 
-   02 - incorporated several minor suggested clarifications.
+3. Framework for the VERP SMTP transport extension
 
-   03 - clarified the "opt-in" proposed compromise in section 8.1
+   This SMTP transport extension [1] is laid out as follows.
 
-   04 - added section 7.2, based on input received.
+      (1) The name of the SMTP transport extension defined here is
+          Variable Envelope Return Path.
 
-1. Abstract
+      (2) The EHLO keyword associated with this extension is VERP.
 
-   This document describes an extension to the SMTP service [RFC1425],
-   called Extended DATA Reply.  This is an extended format of the SMTP
-   response to the DATA verb which provides recipient-specific status
-   information.  This allows mail recipients to use individual mail
-   filters as part of the Simple Mail Transfer Protocol.  This is a very
-   desirable feature because of escalating amounts of unwanted junk E-
+      (3) The VERP EHLO keyword takes no parameters.
 
+      (4) One optional ESMTP keyword VERP is associated with the MAIL
+          FROM command. This parameter takes no values.
+
+      (5) No additional ESMTP verbs are defined by this extension.
+
+      (6) The next section specifies how support for this extension
 
 
-Expires XXX XX, XXXX                                            [Page 1]
+
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 2]
 
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+VERP SMTP Extension          S. Varshavchik                 XXX XX, XXXX
 
 
-   mail sent over the Internet.
+          affects the behavior of a server and client SMTP.
 
-2. Introduction
+4. The VERP SMTP extension
 
-   The reply to the SMTP [RFC821] DATA verb is a status code indicating
-   if the message was accepted or rejected.  The status code also
-   indicates if the rejection is temporary or permanent.  Additional
-   delivery attempts will be made for messages that are temporarily
-   rejected.
-
-   SMTP allows a message to have multiple recipients, but the reply to
-   the DATA verb cannot indicate if the message was successfully
-   accepted for some recipients only and rejected for the remaining
-   recipients (permanently or temporarily).  It can only indicate if the
-   message was accepted or rejected for every one of the listed
-   recipients.
-
-   The only way to handle this condition within the current protocol is
-   to send a status code indicating that the message was accepted, then
-   immediately generate a non-delivery report for undeliverable
-   recipients.  This imposes additional resources and overhead to
-   generate and transmit the non-delivery report.
-
-   The ability to have recipient-specific status in the reply to the
-   DATA verb is desirable for the following reasons:
-
-        A) The receiving SMTP server does not have to generate and send
-           a non-delivery report.
-
-        B) Recipients can install individual mail filters that
-           selectively block unwanted E-mail, and the mail filters will
-           be able to examine the entire contents of the message before
-           deciding to reject the message.  Currently, recipient-
-           specific filtering is only possible in response to the "RCPT
-           TO:" verb.  But the only available information at that point
-           is the network address of the sending SMTP agent and return
-           address of the message.  Filtering unwanted junk mail based
-           only on the network address and the return address is of very
-           limited benefit.
-
-   There are several other mail enhancements that involve recipient-
-   specific processing.  [RFC2033] defines a related, but a completely
-   different, mail delivery protocol which features recipient-specific
-   processing.  There was also another draft memo published, draft-ietf-
-   fax-smtp-session, which defined an extension for recipient-specific
-   mail processing, however its scope is different from the scope of
-   this memo.
+   When a VERP keyword is present in the MAIL FROM command, [4], some
+   additional restrictions are imposed on the RFC 822 address [5],
+   specified by that MAIL FROM command, and on all RFC 822 addresses in
+   the subsequent RCPT TO commands that refer to the same message (that
+   is, until the next DATA, RSET, or QUIT command).  The term "VERP
+   message" refers to any E-mail message whose MAIL FROM command
+   includes the VERP keyword.  The term "VERP-compliant server" refers
+   to any E-mail server that supports the Variable Envelope Return Path
+   SMTP extension.  When a VERP keyword is present in the MAIL FROM
+   command:
 
+       (1) The address specified by the MAIL FROM verb MUST contain at
+           least one @ character.
 
+       (2) The address in every RCPT TO verb referring to the same
+           message MUST contain at least one @ character.
 
+       (3) The domain portion of the address in the MAIL FROM and RCPT
+           TO verbs MUST be compliant with the definition of <domain> in
+           [6].  That is, it MUST contain only letters, digits, hyphens,
+           and periods.  The domain portion of the address is the one
+           that follows the last @ character.
 
-Expires XXX XX, XXXX                                            [Page 2]
+4.1 Delivery failures
+
+   When a VERP-compliant server is unable to deliver a VERP message to
+   one or more recipients, the VERP server MUST do one of the following:
+
+        1) Return an RFC 1891 delivery status notification to the return
+           address, or:
+
+        2) Transmit a separate non-delivery notice for each failed
+           recipient.  The return address for each non-delivery notice
+           MUST be the address thatâs formed by applying the procedure
+           described in section 7 of this document to the return address
+           of the message and the failed recipientâs address.  If more
+           than one recipient was undeliverable a separate notice MUST
+           be sent for each undeliverable address.
+
+5. Final delivery
+
+   Section 4.3.1 of [5] specifies that the mail server performing final
+   delivery of a message will generate a Return-Path: header containing
+   the return address of the message.
+
+
+
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 3]
 
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+VERP SMTP Extension          S. Varshavchik                 XXX XX, XXXX
 
 
-3. Framework for the EXDATA SMTP transport extension
+   This return address MUST be formed by applying the procedure
+   described in section 7 of this document to the return address and the
+   recipientâs address.
+
+   This also applies if the mail server invokes some other external
+   process to handle final delivery, instead of placing the message into
+   the recipientâs mailbox. In all cases, the return address specified
+   by the mail server to any external environment or process MUST be
+   derived by applying the procedure in section 7 to the return address
+   and the recipientâs address.
+
+6. Relaying
+
+   When a VERP-compliant server determines that a recipient of a VERP
+   message is not a local mailbox, and the message must be relayed to
+   another server, the VERP-compliant server MUST:
+
+       (1) If the VERP-compliant serverâs local policies require the
+           return and/or recipient addresses are to be rewritten, the
+           VERP-compliant server MUST make sure that delivery notices
+           MUST NOT be sent to a rewritten return address, or reflect a
+           rewritten recipient address, unless separate arrangements are
+           made with the sender of the VERP message.  This is because
+           the sender expects to be able to resolve non-delivery notices
+           to some recipient address it knows about (irrespective
+           whether the addresses are resolved from a VERP, or from a
+           delivery status notification in the format specified by [2]).
+           When local policies of the relaying server require the
+           recipient or the sender address to be rewritten, the sender
+           will obviously be not aware of this rewriting or expansion.
+           If a subsequent delivery failure results in a non-delivery
+           notice being sent to a VERP containing the rewritten address,
+           the sender will not be able to associate the address encoded
+           in the VERP with any recipient address it has on file.
+
+           A suggested way to handle this situation is to set specify a
+           delivery status notification of "NEVER" - as specified by [3]
+           - for any recipient address generated by local aliasing or
+           rewriting, and treat the original address as being either
+           delivered or relayed, resulting in a "delivered" or "relayed"
+           delivery status notification if the original recipient
+           address specified a "SUCCESS" notification.
+
+           Note that this clause does not prohibit the relaying server
+           to have an established agreement with the sender to act as a
+           mailing list exploder, as long as this agreement is handled
+           in a transparent way.  For example, the relaying server can
+           set its own return address on all VERP messages it exploded,
 
-   This SMTP transport extension [RFC1425] is laid out as follows.
 
-      (1) The name of the SMTP transport extension defined here is
-          Extended Data Reply (EXDATA).
 
-      (2) The EHLO keyword associated with this extension is EXDATA.
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 4]
+
+VERP SMTP Extension          S. Varshavchik                 XXX XX, XXXX
 
-      (3) The EXDATA EHLO keyword takes no parameters.
 
-      (4) One optional ESMTP keyword EXDATA is associated with the MAIL
-          FROM command. This parameter takes no values.
+           and handle non-delivery notices all by itself.
 
-      (5) No additional ESMTP verbs are defined by this extension.
+       (2) If the VERP-compliant server determines that the remote
+           server is also a VERP compliant server, the VERP keyword MUST
+           be included in the MAIL FROM command used to relay the VERP
+           message to the remote server.
+
+       (3) If the remote server is not a VERP compliant server, The VERP
+           compliant server SHOULD send a separate copy of the message
+           for every recipient.  The return address of each copy of the
+           message MUST be formed by applying the procedure described in
+           section 7 of this document to the original return address,
+           and the address of each individual recipient.  Although the
+           message SHOULD NOT be returned as undeliverable, if it is
+           then the rules defined in section 4.1 MUST be applied.
 
-      (6) The next sections specify how support for this extension
-          affects the behavior of a server and client SMTP server.
+           These rules also apply if the SMTP-compliant server
+           determines that the VERP message must be forwarded via some
+           other protocol to a non-SMTP gateway, unless the non-SMTP
+           protocol has equivalent features that are completely
+           identical in function to Variable Envelope Return Path SMTP
+           service extension (including any translations of E-mail
+           addresses to and from the non-RFC822 format).
 
-4. The EXDATA SMTP extension
+7. Variable envelope return path encoding
 
-   The receiving SMTP server indicates that it is capable of supporting
-   the Extended Data Reply SMTP extension by including the EXDATA
-   keyword in the EHLO list.
+   This encoding method starts with a return address and one recipient
+   address.  As mentioned previously, both addresses MUST be valid
+   RFC822 addresses, [5], and MUST contain at least one @ character.
+   The portion of each address following the last @ character MUST be
+   compliant with [6], or must be an explict network address literal,
+   for example: john43@[192.68.0.4].
 
-   The sending SMTP agent indicates that it supports this extension by
-   including the EXDATA keyword in the MAIL FROM command.
+   Let "sdomain" represent the portion of the return address that
+   follows the last @ character.
 
-   If the sending SMTP agent includes the EXDATA keyword in the first
-   MAIL FROM command, it MUST include the keyword in every MAIL FROM
-   command used in the same SMTP session.  If the sending SMTP agent
-   does not include the EXDATA keyword in the first MAIL FROM command,
-   it MUST NOT include the keyword in any MAIL FROM command used in the
-   same SMTP session.
+   Let "slocal" represent the portion of the return address that
+   precedes the last @ character.
 
-   The receiving SMTP server SHOULD NOT send extended replies to the
-   DATA verb if the EXDATA keyword is not included in the MAIL FROM
-   command.
+   Let "rdomain" represent the portion of the recipient address that
+   follows the last @ character.
 
-   An extended DATA verb reply MAY be sent instead of the second status
-   code reply to the DATA verb. It MUST NOT be sent as the first reply
-   to the DATA verb (before the message is transmitted).  Using the
-   extended format in the second reply to the DATA verb is optional, and
-   not required.  The receiving SMTP server is always permitted to send
-   regular status replies.
+   Let "rlocal" represent the portion of the recipient address that
+   precedes the last @ character.
 
-5. Format of an extended SMTP DATA reply
+   To encode the recipient address within the envelope sender address,
+   create an address of the following form:
 
 
 
 
-Expires XXX XX, XXXX                                            [Page 3]
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 5]
 
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+VERP SMTP Extension          S. Varshavchik                 XXX XX, XXXX
 
 
-   The extended SMTP DATA reply uses the 558 numeric status code which
-   is explicitly reserved for this purpose.  When a 558 numeric status
-   code is the second reply to the DATA verb, the reply MUST be
-   formatted as follows, where <SP>, <CR> and <LF> represent the ASCII
-   space, carriage return, and line feed characters:
+          slocal-encodedrlocal=encodedrdomain@sdomain
 
-   ex-reply-code: ex-reply-recipient-list
+   Where "encodedrlocal" and "encodedrdomain" are formed by taking
+   rlocal and rdomain, respectively, and encoding each one as follows:
 
-   ex-reply-recipient-list: non-final-recipient ex-reply-recipient-list
-                       | final-recipient
+        1) Each @, :, %, !, -, [, ], and + character in rlocal is
+           replaced by a single â+â character followed by two uppercase
+           hexadecimal characters whose value is the ASCII code of the
+           replaced character.
 
-   non-final-recipient: non-term-line non-final-recipient
-                        | non-final-recipient-term-line
+           Taking into account poorly-written mail relays that ignore
+           case-sensitivity, both uppercase and lowercase hexadecimal
+           characters SHOULD be recognized when decoding envelope return
+           paths.
 
-   non-term-line: "558-" result-code "-" result-text
+        2) All other characters are unchanged.  Other characters MAY,
+           but SHOULD NOT be also encoded in the same fashion.
 
-   non-final-recipient-term-line: "558-" result-code <SP> result-text
+   This can be represented using BNF as follows:
 
-   final-recipient: non-term-line final-recipient
-                    | final-recipient-term-line
+     encodedverp: slocal "-" encodedrlocal "=" encodedrdomain "@" sdomain
 
-   final-recipient-term-line: "558" <SP> result-code <SP> result-text
+     encodedrlocal: * (char-literal / char-encoded )
 
-   result-code: digit digit digit
+     encodedrdomain: * (char-literal / char-encoded )
 
-   result-text: 0 or more characters, except <CR> and <LF>, terminated
-                by the <CR> <LF> sequence
+     char-literal: any character valid in an RFC821 address [4],
+                   except @, :, %, !, [, ], -, and +
 
-   digit: Characters "0" through "9"
+     char-encoded: "+" hexdigit hexdigit
 
+     hexdigit: ("0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
+                "9" / "A" / "B" / "C" / "D" / "E" / "F" /
+                      "a" / "b" / "c" / "d" / "e" / "f")
 
-   The extended DATA reply is formatted like a standard multiline SMTP
-   reply with a 558 numeric status code.  The extended information is
-   contained within the text portion of the 558 multiline reply.  The
-   extended information consists of one or more individual replies,
-   where each reply itself is formatted like an SMTP reply.  There will
-   be exactly one reply for each recipient.  Each individual reply may
-   be a multiline reply itself.
+8. Variable envelope return path decoding
 
-6. Restrictions on the extended SMTP DATA reply
+   Non-delivery notices for VERP messages will be sent to either the
+   original address, <slocal@sdomain>, or to the VERP-encoded address,
+   <slocal-encodedrlocal=encodedrdomain@sdomain>.
 
-   Extended replies MUST contain exactly one individual reply for each
-   recipient whose RCPT TO command was acknowledged with a 2xx result
-   code.  Extended replies MUST NOT have any replies for recipients
-   whose RCPT TO commands were previously rejected with a 4xx or 5xx
-   result code.
+   Messages sent to <slocal@sdomain> will be RFC 1891-compliant delivery
+   status notifications.  These messages will be machine-readable, and
+   the mail software will be able to identify failed addresses from the
+   RFC 1891 delivery report.
 
-   For example, if a message had three recipients, and the second RCPT
+   Non-delivery notices will also be sent to the VERP-encoded address,
+   and the mail software will be able to reconstruct the failed address
 
 
 
-Expires XXX XX, XXXX                                            [Page 4]
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 6]
 
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+VERP SMTP Extension          S. Varshavchik                 XXX XX, XXXX
+
+
+   from the VERP-encoded address by simply reversing the steps used in
+   encoding:
 
+        1) Extract encodedrlocal and rdomain from the recipient address.
+           There will be at least one = character in the encoded portion
+           of the return address.  encodedrlocal is everything up to the
+           last = character.  Everything following the last = character
+           is encodedrdomain.
+
+        2) Replacing all occurrences of "+" followed by two hexadecimal
+           digits in encodedrlocal and encodedrdomain with the
+           equivalent ASCII character.
+
+        3) Using the decoded rlocal, @, then rdomain.
+
+9. Examples
+
+   Suppose that a VERP-compliant server named "example.com" receives a
+   message via the following SMTP conversation (for brevity, non-
+   relevant headers have been omitted):
+
+       220 example.com ESMTP
+       EHLO domain.com
+       250-example.com ESMTP
+       250-SIZE
+       250-DSN
+       250-VERP
+       250 HELP
+       MAIL FROM:<itny-out@domain.com> VERP SIZE=100
+       250 Ok
+       RCPT TO:<alex@example.com>
+       250 Ok
+       RCPT TO:<node42!ann@old.example.com>
+       250 Ok
+       RCPT TO:<tom@old.example.com>
+       250 Ok
+       RCPT TO:<lisa@new.example.com>
+       250 Ok
+       RCPT TO:<dave+priority@new.example.com>
+       250 Ok
+       DATA
+       354 Ok
+       From: "John" <john@domain.com>
+       Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST)
+       Subject: Meeting canceled.
 
-   TO command was rejected, the extended reply MUST contain two
-   individual replies: the first one is for the first recipient, the
-   second one for the last recipient.
+       Todayâs 2pm meeting has been rescheduled for tomorrow, 9am, due
+       to a scheduling conflict.
 
-   Technically, an extended SMTP DATA reply with a 2xx numeric code in
-   every individual reply is technically equivalent to a regular 2xx
-   reply to the DATA transaction.  The "be conservative with what you
-   send, and be liberal with what you receive" principle would dictate
-   that the sending SMTP agent MUST be prepared to properly handle
-   either reply, and the receiving SMTP agent SHOULD use a regular 2xx
-   response in this situation.
 
-7.  Examples
 
-   In this example the first recipient of a two-recipient message is
-   accepted.  The second recipient is rejected:
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 7]
+
+VERP SMTP Extension          S. Varshavchik                 XXX XX, XXXX
+
+
+       .
 
-   558-250 Message accepted
-   558-550-Access denied:
-   558 550 Insufficient permission
+   The message is delivered to the local mailbox for <alex@example.com>.
+   The message looks like this:
 
-   In this example the first recipient is rejected. The second recipient
-   is accepted:
+       Return-Path: <itny-out-alex=example.com@domain.com>
+       From: "John" <john@domain.com>
+       Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST)
+       Subject: Meeting canceled.
+
+       Todayâs 2pm meeting has been rescheduled for tomorrow, 9am, due
+       to a scheduling conflict.
+
+   The VERP-compliant server at example.com connects to the mail server
+   for old.example.com.  old.example.com does not support the Variable
+   Envelope Return Path extension.  Therefore, old.example.com receives
+   two messages.  The SMTP conversation for the first message is as
+   follows:
+
+       220 old.example.com ESMTP
+       EHLO example.com
+       250-old.example.com ESMTP
+       250-SIZE
+       250-DSN
+       250 HELP
+       MAIL FROM:<itny-out-node42+21ann=old.example.com@domain.com>
+       250 Ok
+       RCPT TO:<node42!ann@old.example.com>
+       250 Ok
+       DATA
+       354 Ok
+       From: "John" <john@domain.com>
+       Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST)
+       Subject: Meeting canceled.
+
+       Todayâs 2pm meeting has been rescheduled for tomorrow, 9am, due
+       to a scheduling conflict.
+       .
+
+   The SMTP conversation for the second message is as follows:
+
+       MAIL FROM:<itny-out-tom=old.example.com@domain.com>
+       250 Ok
+       RCPT TO:<tom@old.example.com>
+       250 Ok
+       DATA
+       354 Ok
+       From: "John" <john@domain.com>
 
-   558-550-Access denied
-   558-550 Insufficient permission
-   558-250-Message accepted
-   558 250 Queue ID is 120
 
 
-7.1 Parsing extended replies
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 8]
+
+VERP SMTP Extension          S. Varshavchik                 XXX XX, XXXX
+
 
-   Extended replies can be parsed rather easily by noting that extended
-   replies are wrapped inside a standard SMTP multiline reply with a 558
-   status code.  If the numeric code of the second status reply to the
-   DATA verb is 558, and if the receiving server listed EXDATA in the
-   EHLO keyword list, the "558-" and "558<SP>" characters are removed
-   from the start of every line in the multiline response. The remaining
-   text is now interpreted as a series of individual SMTP replies, one
-   reply per recipient.  Each individual reply may be a multiline reply
-   itself.
+       Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST)
+       Subject: Meeting canceled.
 
-7.2 Parsing incomplete replies
+       Todayâs 2pm meeting has been rescheduled for tomorrow, 9am, due
+       to a scheduling conflict.
+       .
+
+   example.com connects to new.example.com and determines that
+   new.example.com runs a modern ESMTP server that supports the VERP
+   keyword. The SMTP conversation then goes like this:
+
+       220 new.example.com ESMTP
+       EHLO example.com
+       250-new.example.com ESMTP
+       250-SIZE
+       250-DSN
+       250-VERP
+       250 HELP
+       MAIL FROM:<itny-out@domain.com> VERP SIZE=100
+       250 Ok
+       RCPT TO:<lisa@new.example.com>
+       250 Ok
+       RCPT TO:<dave+priority@new.example.com>
+       250 Ok
+       DATA
+       354 Ok
+       From: "John" <john@domain.com>
+       Date: Thu, 16 Jan 1997 14:49:31 -0500 (EST)
+       Subject: Meeting canceled.
+
+       Todayâs 2pm meeting has been rescheduled for tomorrow, 9am, due
+       to a scheduling conflict.
+       .
+
+10. Security concerns
+
+   All the usual security considerations applicable to SMTP are also
+   applicable to this extension.  Relay of VERP messages to non-VERP
+   servers requires a single message with many recipients to be exploded
+   into many messages with one recipient.  In all cases, however, there
+   will never be any additional overhead beyond the resources that are
+   required when VERPs are manually implemented by the mail sender,
+   instead of the VERP SMTP extension.
+
+   Mail systems which support the VERP extension SHOULD have adequate
+   security measures, including blocks against unauthorized access and
+   relaying.
 
-   If the client receives an incomplete 558 reply, the client should
-   process normally any of this replyâs subreplies which were received
-   in their entirety, and should process any incomplete or unreceived
-   subreplies as if they had been 451 subreplies.
 
 
 
-Expires XXX XX, XXXX                                            [Page 5]
+S. Varshavchik            Expires XXX XX, XXXX                  [Page 9]
 
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+VERP SMTP Extension          S. Varshavchik                 XXX XX, XXXX
 
 
-   While receiving a 558 reply, the client must implement a timeout of
-   at least 10 minutes per subreply.  It MUST use per- subreply timeouts
-   rather than trying to time the entire 558 reply.  This means that the
-   overall timeout is approximately proportional to the number of
-   recipients.
+10.1 Vacation programs, and other autoresponders
 
-   Rationale: The 10 minute limit is chosen because thatâs the suggested
-   minimum timeout for processing a message body, in the middle of
-   section 4.5.3.2 of RFC 2821.  The second and third sentences above
-   are adapted from the first paragraph of that same section of the RFC.
+   "Vacation" type autoresponders are often used in practice.  A
+   vacation autoresponder is a program that automatically replies to
+   every message, informing the sender that the recipient is on
+   vacation, or is generally unavailable at this time.
 
-   While sending a 558 reply, the server should take no more than about
-   5 minutes to send each subreply.  If individual users administer
-   their own filtering software, it would be advisable to use a timeout
-   mechanism to force a decision after 5 minutes.
+   Vacation autoresponders MUST NOT generate autoresponses to mailing
+   list messages, but people often forget to do set them up to do so.
+   Because autoresponses are sent to the same address thatâs used to
+   receive non-delivery reports, malfunctioning autoresponders result in
+   the recipient being removed from mailing lists.
 
-   Rationale: if a userâs filter always takes too long, and triggers the
-   clientâs 10 minute timeout, other users might not ever be able to
-   receive the message.
+   Advanced autoresponders send automatic replies in the format
+   specified by [2], as a "delayed" notification.  DSN-aware software
+   will not remove addresses from mailing lists due to delayed
+   notifications.
+
+   Section 5 of this document specifies that the mail server MUST
+   replace the original return address with a VERP-modified address when
+   delivering the message to a mailbox or an external process.
+
+   Therefore it is possible that RFC 1891 reports may also be sent to a
+   VERP-encoded address, as specified by sections 5 and 7 of this
+   document.  Mail software SHOULD ignore any RFC 1891 "delayed" or
+   "success" reports that sent to a VERP-encoded address.  If it is a
+   "failed" report, note that the VERP address will be more reliable
+   than the address specified in the report itself.
 
-8.  Security Concerns
 
-8.1 Transitional behavior
 
-   The stated benefit of this extension is to allow recipients to use
-   individual mail filters to reject mail during an SMTP transaction.
-   However this extension must be widely implemented for this to happen.
-   Furthermore, the sending SMTP agent can always omit the EXDATA
-   keyword from the MAIL FROM: verb.
 
-   It follows that recipient-specific mail filtering is still a very
-   desireable feature if the sending SMTP agent does not state its
-   support for the EXDATA extension.  One approach is to reply to the
-   DATA verb with an accepted status, then apply individual filters and
-   generate a non-delivery report for recipients whose filters rejected
-   the message.  But this would be exactly how individual mail filtering
-   is currently implemented, and it carries with it the same
-   disadvantages and setbacks.
 
-   Another possible approach is to go ahead and issue an extended reply,
-   which will be interpreted as a permanent failure by the sending SMTP
-   agent.  This approach is usually unacceptable because the sending
-   SMTP agent will correctly conclude that every recipient was
-   undeliverable.  If a message comes from a mailing list, the mailing
-   list software can end up removing all recipients from the mailing
-   list only because of a malfunctioning mail filter used by one
-   recipient only.
 
 
 
 
-Expires XXX XX, XXXX                                            [Page 6]
-
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
 
 
-   Hereâs an approach that attempts to achieve a compromise between
-   having recipient-specific mail filtering, and avoiding unwanted
-   disruptions of this kind.
 
-        A) Recipients must explicitly enable the ability to set
-           filtering rules for their mailboxes
 
-        B) Allow each recipient to specify "whitelisted" senders and/or
-           network addresses.  The mail server will not do any filtering
-           on white-listed mail, and will never send EXDATA-formatted
-           replies to those sources.
 
-        C) When the first valid RCPT TO: verb is received (after zero or
-           more RCPT TO: verbs that were deemed to be unacceptable for
-           any other reason), determine if the first recipient has this
-           sender whitelisted.
 
-        D) If the message is whitelisted by the first accepted
-           recipient, any additional recipients MUST also have the
-           message similarly whitelisted.  If not, reject the
-           corresponding RCPT TO: verb with a temporary 421 status code.
-           The sending SMTP agent is expected to retransmit the message
-           for all non whitelisted recipients after a small delay.
 
-        E) If the message is not whitelisted by the first recipient, any
-           additional recipients MUST NOT have this message whitelisted
-           If they do, reject the corresponding RCPT TO: verb with a
-           temporary 421 status code.  The sending SMTP agent is
-           expected to retransmit the message for all whitelisted
-           recipients after a small delay.
 
-        E) This logic results in separate delivery attempts for
-           whitelisted and non whitelisted recipients (with a small
-           delay in between).  Individual recipients can decide whether
-           to whitelist specific sources of mail (such as mailing
-           lists).  By whitelisting known mail sources, the recipients
-           can make sure that anyone elseâs mail filter will not affect
-           their mail delivery.
 
-8.2 Response time to SMTP DATA
 
-   Implementations should try to avoid any lengthy delays due to mail
-   filters being used, before returning a reply to the SMTP DATA.  Many
-   SMTP clients wait for a response for only a short period of time,
-   before giving up.  This can lead to a message duplication problem,
-   described in [RFC1047].
 
-9. Comments
 
 
 
-Expires XXX XX, XXXX                                            [Page 7]
+S. Varshavchik            Expires XXX XX, XXXX                 [Page 10]
 
-EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
+VERP SMTP Extension          S. Varshavchik                 XXX XX, XXXX
 
 
-   An experimental patch was made available in September 1997 (with
-   various revisions that followed) to a relatively popular mail server.
-   The patch used an XEXDATA EHLO keyword.  The experimental patch was
-   mainly used to implement recipient-specific mail filtering:
-   permitting individual recipients of a message to selectively reject
-   incoming E-mail traffic based on the contents of the message.  The
-   patch implemented the XEXDATA extension only for the receiving side,
-   not for the sending side.
-
-   No issues have been reported concerning the theoretical design of the
-   extended result code.
-
-10. References
-
-       [RFC1425] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
-           Crocker, D.  "SMTP Service Extensions", RFC 1425, United
-           Nations University, Innosoft International, Inc., Dover Beach
+11. References
+
+       [1] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D.
+           "SMTP Service Extensions", RFC 1425, United Nations
+           University, Innosoft International, Inc., Dover Beach
            Consulting, Inc., Network Management Associates, Inc., The
            Branch Office, February 1993
 
-       [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
-           821, USC/Information Sciences Institute, August 1982.
+       [2] Moore, K., and G. Vaudreuil, "An Extensible Message Format
+           for Delivery Status Notifications", RFC 1894, University of
+           Tennessee, Octel Network Services, January 1996.
+
+       [3] Moore, K. "SMTP Service Extension for Delivery Status
+           Notifications", RFC 1891, University of Tennessee, January
+           1996.
 
-       [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
-           Carnegie Mellon, October 1996.
+       [4] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+           USC/Information Sciences Institute, August 1982.
 
-       [RFC1047] Partridge, C., "DUPLICATE MESSAGES AND SMTP", RFC 1047,
-           CIC at BBN Labs, February 1988.
+       [5] Crocker, D., "Standard for the Format of ARPA Internet Text
+           Messages", STD 11, RFC 822, UDEL, August 1982.
 
-11. Authorâs address
+       [6] Mockapetris, P., "Domain Names - Implementation and
+           Specification", RFC 1035, ISI, November 1987
+
+12. Authorâs address
 
    Sam Varshavchik
    Double Precision, Inc.
-   PO Box 637
-   Harriman, NY 10926
+   402 Main Street Suite 100-241
+   Metuchen, NJ 08840
    <mrsam@courier-mta.com>
 
 
@@ -447,4 +611,8 @@
 
 
 
-Expires XXX XX, XXXX                                            [Page 8]
+
+
+
+
+S. Varshavchik            Expires XXX XX, XXXX                 [Page 11]
