"Fossies" - the Fresh Open Source Software Archive

Member "courier-1.2.2/courier/doc/draft-varshavchik-exdata-smtpext.txt" (25 Aug 2013, 15924 Bytes) of package /linux/misc/courier-1.2.2.tar.bz2:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    7 1. Abstract
    9    This document describes an extension to the SMTP service [RFC1425],
   10    called Extended DATA Reply.  This is an extended format of the SMTP
   11    response to the DATA verb which provides recipient-specific status
   12    information.  This allows mail recipients to use individual mail
   13    filters as part of the Simple Mail Transfer Protocol.  This is a very
   14    desirable feature because of escalating amounts of unwanted junk E-
   15    mail sent over the Internet.
   17 2. Introduction
   19    The reply to the SMTP [RFC821] DATA verb is a status code indicating
   20    if the message was accepted or rejected.  The status code also
   21    indicates if the rejection is temporary or permanent.  Additional
   22    delivery attempts will be made for messages that are temporarily
   23    rejected.
   25    SMTP allows a message to have multiple recipients, but the reply to
   26    the DATA verb cannot indicate if the message was successfully
   27    accepted for some recipients only and rejected for the remaining
   28    recipients (permanently or temporarily).  It can only indicate if the
   29    message was accepted or rejected for every one of the listed
   30    recipients.
   32    The only way to handle this condition within the current protocol is
   33    to send a status code indicating that the message was accepted, then
   34    immediately generate a non-delivery report for undeliverable
   35    recipients.  This imposes additional resources and overhead to
   36    generate and transmit the non-delivery report.
   38    The ability to have recipient-specific status in the reply to the
   39    DATA verb is desirable for the following reasons:
   41         A) The receiving SMTP server does not have to generate and send
   42            a non-delivery report.
   44         B) Recipients can install individual mail filters that
   45            selectively block unwanted E-mail, and the mail filters will
   46            be able to examine the entire contents of the message before
   47            deciding to reject the message.  Currently, recipient-
   48            specific filtering is only possible in response to the "RCPT
   49            TO:" verb.  But the only available information at that point
   50            is the network address of the sending SMTP agent and return
   51            address of the message.  Filtering unwanted junk mail based
   52            only on the network address and the return address is of very
   53            limited benefit.
   58 Expires XXX XX, XXXX                                            [Page 1]
   60 EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
   63    There are several other mail enhancements that involve recipient-
   64    specific processing.  [RFC2033] defines a related, but a completely
   65    different, mail delivery protocol which features recipient-specific
   66    processing.  There was also another draft memo published, draft-ietf-
   67    fax-smtp-session, which defined an extension for recipient-specific
   68    mail processing, however its scope is different from the scope of
   69    this memo.
   71 3. Framework for the EXDATA SMTP transport extension
   73    This SMTP transport extension [RFC1425] is laid out as follows.
   75       (1) The name of the SMTP transport extension defined here is
   76           Extended Data Reply (EXDATA).
   78       (2) The EHLO keyword associated with this extension is EXDATA.
   80       (3) The EXDATA EHLO keyword takes no parameters.
   82       (4) One optional ESMTP keyword EXDATA is associated with the MAIL
   83           FROM command. This parameter takes no values.
   85       (5) No additional ESMTP verbs are defined by this extension.
   87       (6) The next sections specify how support for this extension
   88           affects the behavior of a server and client SMTP server.
   90 4. The EXDATA SMTP extension
   92    The receiving SMTP server indicates that it is capable of supporting
   93    the Extended Data Reply SMTP extension by including the EXDATA
   94    keyword in the EHLO list.
   96    The sending SMTP agent indicates that it supports this extension by
   97    including the EXDATA keyword in the MAIL FROM command.
   99    If the sending SMTP agent includes the EXDATA keyword in the first
  100    MAIL FROM command, it MUST include the keyword in every MAIL FROM
  101    command used in the same SMTP session.  If the sending SMTP agent
  102    does not include the EXDATA keyword in the first MAIL FROM command,
  103    it MUST NOT include the keyword in any MAIL FROM command used in the
  104    same SMTP session.
  106    The receiving SMTP server SHOULD NOT send extended replies to the
  107    DATA verb if the EXDATA keyword is not included in the MAIL FROM
  108    command.
  110    An extended DATA verb reply MAY be sent instead of the second status
  114 Expires XXX XX, XXXX                                            [Page 2]
  116 EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
  119    code reply to the DATA verb. It MUST NOT be sent as the first reply
  120    to the DATA verb (before the message is transmitted).  Using the
  121    extended format in the second reply to the DATA verb is optional, and
  122    not required.  The receiving SMTP server is always permitted to send
  123    regular status replies.
  125 5. Format of an extended SMTP DATA reply
  127    The extended SMTP DATA reply uses the 558 numeric status code which
  128    is explicitly reserved for this purpose.  When a 558 numeric status
  129    code is the second reply to the DATA verb, the reply MUST be
  130    formatted as follows, where <SP>, <CR> and <LF> represent the ASCII
  131    space, carriage return, and line feed characters:
  133    ex-reply-code: ex-reply-recipient-list
  135    ex-reply-recipient-list: non-final-recipient ex-reply-recipient-list
  136                        | final-recipient
  138    non-final-recipient: non-term-line non-final-recipient
  139                         | non-final-recipient-term-line
  141    non-term-line: "558-" result-code "-" result-text
  143    non-final-recipient-term-line: "558-" result-code <SP> result-text
  145    final-recipient: non-term-line final-recipient
  146                     | final-recipient-term-line
  148    final-recipient-term-line: "558" <SP> result-code <SP> result-text
  150    result-code: digit digit digit
  152    result-text: 0 or more characters, except <CR> and <LF>, terminated
  153                 by the <CR> <LF> sequence
  155    digit: Characters "0" through "9"
  158    The extended DATA reply is formatted like a standard multiline SMTP
  159    reply with a 558 numeric status code.  The extended information is
  160    contained within the text portion of the 558 multiline reply.  The
  161    extended information consists of one or more individual replies,
  162    where each reply itself is formatted like an SMTP reply.  There will
  163    be exactly one reply for each recipient.  Each individual reply may
  164    be a multiline reply itself.
  166 6. Restrictions on the extended SMTP DATA reply
  170 Expires XXX XX, XXXX                                            [Page 3]
  172 EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
  175    Extended replies MUST contain exactly one individual reply for each
  176    recipient whose RCPT TO command was acknowledged with a 2xx result
  177    code.  Extended replies MUST NOT have any replies for recipients
  178    whose RCPT TO commands were previously rejected with a 4xx or 5xx
  179    result code.
  181    For example, if a message had three recipients, and the second RCPT
  182    TO command was rejected, the extended reply MUST contain two
  183    individual replies: the first one is for the first recipient, the
  184    second one for the last recipient.
  186    Technically, an extended SMTP DATA reply with a 2xx numeric code in
  187    every individual reply is technically equivalent to a regular 2xx
  188    reply to the DATA transaction.  The "be conservative with what you
  189    send, and be liberal with what you receive" principle would dictate
  190    that the sending SMTP agent MUST be prepared to properly handle
  191    either reply, and the receiving SMTP agent SHOULD use a regular 2xx
  192    response in this situation.
  194 7.  Examples
  196    In this example the first recipient of a two-recipient message is
  197    accepted.  The second recipient is rejected:
  199    558-250 Message accepted
  200    558-550-Access denied:
  201    558 550 Insufficient permission
  203    In this example the first recipient is rejected. The second recipient
  204    is accepted:
  206    558-550-Access denied
  207    558-550 Insufficient permission
  208    558-250-Message accepted
  209    558 250 Queue ID is 120
  212 7.1 Parsing extended replies
  214    Extended replies can be parsed rather easily by noting that extended
  215    replies are wrapped inside a standard SMTP multiline reply with a 558
  216    status code.  If the numeric code of the second status reply to the
  217    DATA verb is 558, and if the receiving server listed EXDATA in the
  218    EHLO keyword list, the "558-" and "558<SP>" characters are removed
  219    from the start of every line in the multiline response. The remaining
  220    text is now interpreted as a series of individual SMTP replies, one
  221    reply per recipient.  Each individual reply may be a multiline reply
  222    itself.
  226 Expires XXX XX, XXXX                                            [Page 4]
  228 EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
  231 7.2 Parsing incomplete replies
  233    If the client receives an incomplete 558 reply, the client should
  234    process normally any of this reply’s subreplies which were received
  235    in their entirety, and should process any incomplete or unreceived
  236    subreplies as if they had been 451 subreplies.
  238    While receiving a 558 reply, the client must implement a timeout of
  239    at least 10 minutes per subreply.  It MUST use per- subreply timeouts
  240    rather than trying to time the entire 558 reply.  This means that the
  241    overall timeout is approximately proportional to the number of
  242    recipients.
  244    Rationale: The 10 minute limit is chosen because that’s the suggested
  245    minimum timeout for processing a message body, in the middle of
  246    section of RFC 2821.  The second and third sentences above
  247    are adapted from the first paragraph of that same section of the RFC.
  249    While sending a 558 reply, the server should take no more than about
  250    5 minutes to send each subreply.  If individual users administer
  251    their own filtering software, it would be advisable to use a timeout
  252    mechanism to force a decision after 5 minutes.
  254    Rationale: if a user’s filter always takes too long, and triggers the
  255    client’s 10 minute timeout, other users might not ever be able to
  256    receive the message.
  258 8.  Security Concerns
  260 8.1 Transitional behavior
  262    The stated benefit of this extension is to allow recipients to use
  263    individual mail filters to reject mail during an SMTP transaction.
  264    However this extension must be widely implemented for this to happen.
  265    Furthermore, the sending SMTP agent can always omit the EXDATA
  266    keyword from the MAIL FROM: verb.
  268    It follows that recipient-specific mail filtering is still a very
  269    desireable feature if the sending SMTP agent does not state its
  270    support for the EXDATA extension.  One approach is to reply to the
  271    DATA verb with an accepted status, then apply individual filters and
  272    generate a non-delivery report for recipients whose filters rejected
  273    the message.  But this would be exactly how individual mail filtering
  274    is currently implemented, and it carries with it the same
  275    disadvantages and setbacks.
  277    Another possible approach is to go ahead and issue an extended reply,
  278    which will be interpreted as a permanent failure by the sending SMTP
  282 Expires XXX XX, XXXX                                            [Page 5]
  284 EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
  287    agent.  This approach is usually unacceptable because the sending
  288    SMTP agent will correctly conclude that every recipient was
  289    undeliverable.  If a message comes from a mailing list, the mailing
  290    list software can end up removing all recipients from the mailing
  291    list only because of a malfunctioning mail filter used by one
  292    recipient only.
  294    Here’s an approach that attempts to achieve a compromise between
  295    having recipient-specific mail filtering, and avoiding unwanted
  296    disruptions of this kind.
  298         A) Recipients must explicitly enable the ability to set
  299            filtering rules for their mailboxes
  301         B) Allow each recipient to specify "whitelisted" senders and/or
  302            network addresses.  The mail server will not do any filtering
  303            on white-listed mail, and will never send EXDATA-formatted
  304            replies to those sources.
  306         C) When the first valid RCPT TO: verb is received (after zero or
  307            more RCPT TO: verbs that were deemed to be unacceptable for
  308            any other reason), determine if the first recipient has this
  309            sender whitelisted.
  311         D) If the message is whitelisted by the first accepted
  312            recipient, any additional recipients MUST also have the
  313            message similarly whitelisted.  If not, reject the
  314            corresponding RCPT TO: verb with a temporary 421 status code.
  315            The sending SMTP agent is expected to retransmit the message
  316            for all non whitelisted recipients after a small delay.
  318         E) If the message is not whitelisted by the first recipient, any
  319            additional recipients MUST NOT have this message whitelisted
  320            If they do, reject the corresponding RCPT TO: verb with a
  321            temporary 421 status code.  The sending SMTP agent is
  322            expected to retransmit the message for all whitelisted
  323            recipients after a small delay.
  325         E) This logic results in separate delivery attempts for
  326            whitelisted and non whitelisted recipients (with a small
  327            delay in between).  Individual recipients can decide whether
  328            to whitelist specific sources of mail (such as mailing
  329            lists).  By whitelisting known mail sources, the recipients
  330            can make sure that anyone else’s mail filter will not affect
  331            their mail delivery.
  333 8.2 Response time to SMTP DATA
  338 Expires XXX XX, XXXX                                            [Page 6]
  340 EXDATA SMTP Extension        S. Varshavchik                 XXX XX, XXXX
  343    Implementations should try to avoid any lengthy delays due to mail
  344    filters being used, before returning a reply to the SMTP DATA.  Many
  345    SMTP clients wait for a response for only a short period of time,
  346    before giving up.  This can lead to a message duplication problem,
  347    described in [RFC1047].
  349 9. Comments
  351    An experimental patch was made available in September 1997 (with
  352    various revisions that followed) to a relatively popular mail server.
  353    The patch used an XEXDATA EHLO keyword.  The experimental patch was
  354    mainly used to implement recipient-specific mail filtering:
  355    permitting individual recipients of a message to selectively reject
  356    incoming E-mail traffic based on the contents of the message.  The
  357    patch implemented the XEXDATA extension only for the receiving side,
  358    not for the sending side.
  360    No issues have been reported concerning the theoretical design of the
  361    extended result code.
  363 10. References
  365        [RFC1425] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
  366            Crocker, D.  "SMTP Service Extensions", RFC 1425, United
  367            Nations University, Innosoft International, Inc., Dover Beach
  368            Consulting, Inc., Network Management Associates, Inc., The
  369            Branch Office, February 1993
  371        [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
  372            821, USC/Information Sciences Institute, August 1982.
  374        [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
  375            Carnegie Mellon, October 1996.
  377        [RFC1047] Partridge, C., "DUPLICATE MESSAGES AND SMTP", RFC 1047,
  378            CIC at BBN Labs, February 1988.
  380 11. Author’s address
  382    Sam Varshavchik
  383    Double Precision, Inc.
  384    402 Main Street Suite 100-241
  385    Metuchen, NJ 08840
  386    <mrsam@courier-mta.com>
  394 Expires XXX XX, XXXX                                            [Page 7]