[Top] [All Lists]

fix forwarding: sect. 3.9 of draft-klensin-rfc2821bis

2008-01-27 10:03:56

I wrote:
IMHO, a consistent change should affect all of section 3.9
(Mailing Lists and Aliases), beginning with its title, and
previous sections on relaying (3.4 and 3.6) would implicitly
or explicitly refer to this one. Should I post a tentative

As I received no objections, here's my 2 cents.

3.9. Replacing the Envelope Return Address on Forwarding

   An SMTP-capable host SHOULD support both the alias and the list
   models of address expansion for single or multiple deliveries.  When
   a message is delivered or forwarded to each expanded address, the
   return address in the envelope ("MAIL FROM:") is particularly
   important for administrative purposes, as it is the destination of
   any error messages.  Because of its administrative relevance, this
   address MAY be used to devise local acceptance policies based on the
   entity exerting administrative control on the message
   transportation, e.g. the domain part of the envelope address in
   SPF.  While recognizing the existence of such policies, this
   paragraph only describes general issues intended for efficient and
   reliable transport and delivery of mail messages.

   A server SHOULD allow to change the envelope return address if
   required by local forwarding policies.  If the server changes the
   envelope return address, it MUST also remove the Return-Path
   informative header, if any exists.  However, the message header
   section (RFC2822 [9]) MUST be left unchanged; in particular, the
   "From" field of the header section is unaffected.

      Note: Since RFC1123 [2] banned source routing in the envelope
      return path, error messages did not have to go through the
      reverse path any more.  Therefore, in order to exert any
      administrative control on failed deliveries, it is necessary that
      each forwarding server accurately plans how to change the
      envelope return address.

   An important mail facility is a mechanism for multi-destination
   delivery of a single message, by transforming (or "expanding" or
   "exploding") a pseudo-mailbox address into a list of destination
   mailbox addresses.  When a message is sent to such a pseudo-mailbox
   (sometimes called an "exploder"), copies are forwarded or
   redistributed to each mailbox in the expanded list.  Servers SHOULD
   simply utilize the addresses on the list; application of heuristics
   or other matching rules to eliminate some addresses, such as that of
   the originator, is strongly discouraged.  We classify such a pseudo-
   mailbox as an "alias and similar forwarding" or a "list", depending
   upon the expansion rules.

3.9.1. Alias and similar forwarding

   To expand an alias, the recipient mailer replaces the pseudo-mailbox
   address in the envelope with each of the expanded addresses in
   turn.  The envelope return address SHOULD be changed according to
   local forwarding policies, or left intact in case of lack thereof.
   The message is then delivered or forwarded to each expanded address.

   The server administrator should specify a privacy policy and
   carefully determine the kind of forwarding that each alias expansion
   implies, in order to configure the mailer accordingly.  If an alias
   is meant to conceal its expanded address(es), the envelope return
   address has to be changed so that any error message will not reveal
   the final mailbox name to the message originator.  When forwarding
   for address correction or updating (see section 3.4) a delivery
   failure due to the fact that the updated address has been deleted in
   turn should also reach a person or other entity who is in control of
   removing the relevant alias configuration directive, besides the
   current message originator who, by that time, might have already
   received a 251 response (but see also section 7.7).

3.9.2. List

   The envelope return address MUST be changed to be the address of a
   person or other entity who administers the list.

   A mailing list may be said to operate by "redistribution" rather
   than by "forwarding".  To expand a list, the recipient mailer
   replaces the pseudo-mailbox address in the envelope with each of the
   expanded addresses in turn.  The envelope return address is changed
   so that all error messages generated by the final deliveries will be
   returned to a list administrator, not to the message originator, who
   generally has no control over the contents of the list and will
   typically find error messages annoying.

<Prev in Thread] Current Thread [Next in Thread>