Date: Sat, 08 Jul 2000 13:21:22 -0400
From: John C Klensin <klensin@jck.com>
Subject: Re: The 551/251 question
In-reply-to: <23518.963030648@mundamutti.cs.mu.OZ.AU>
To: Robert Elz <kre@munnari.oz.au>
Cc: drums@cs.utk.edu
Message-id: <989808016.963062482@P2>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="==========989813775=========="

--==========989813775==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--On Saturday, 08 July, 2000 14:30 +1000 Robert Elz
<kre@munnari.OZ.AU> wrote:

>     Date:        Fri, 07 Jul 2000 17:14:00 -0400
>     From:        John C Klensin <klensin@jck.com>
>     Message-ID:  <917366236.962990040@P2>
> 
>   | The consensus seems to be to deprecate both of these.
> 
> Really?
>...

Ok.  I'm not sure I believe that either, and can argue this
either way (although probably not as persuasively as you have).
Where there does seem to be clear agreement is that automated
client-side address book updating is rarely implemented,
especially in a consistent fashion, these days.  It seems to me
(I may be wrong) that the strongest objection to leaving these
codes in the spec are associated with the server making the
assumption that updating service will occur when the codes are
returned.  If so, an alternate possibility is to leave the codes
in the spec, make it clear that returning them is optional,
caution about inadvertent information disclosure, and make it
clear that address book updating can't be counted on.

I am attaching a draft replacement for section 3.4, a
modification for the Security Considerations section, and
updating notes for a few other pieces.  If the WG (and the Chair
and ADs) like this better and all can live with it, I'll
substitute it before sending the draft off to the I-D process
tomorrow evening.

      john

--==========989813775==========
Content-Type: text/plain; charset=iso-8859-1; name="smtpupd12bx.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="smtpupd12bx.txt"; size=2674

251/551 alternate model...

-----

3.4 Forwarding for Address Correction or Updating

Forwarding support is most often required to consolidate and =
simplify
addresses within, or relative to, some enterprise and less =
frequently to
establish addresses to link a person's prior address with =
current one.
Silent forwarding of messages (without server notification to =
the sender),
for security or non-disclosure purposes, is common in the =
contemporary
Internet.

In both the enterprise and the "new address" cases, information =
hiding (and
sometimes security) considerations argue against exposure of the =
"final"
address through the SMTP protocol as a side-effect of the =
forwarding
activity.  This may be especially important when the final =
address may not
even be reachable by the sender.  Consequently, the "forwarding" =
mechanisms
described in section 3.2 of RFC 821, and especially the 251 =
(corrected
destination) and 551 reply codes from RCPT must be evaluated =
carefully by
implementers and, when they are available, by those configuring =
systems.

In particular:

* Servers MAY forward messages when they are aware of an address =
change.
  When they do so, they MAY either provide address-updating =
information
  with a 251 code, or may forward "silently" and return a 250 =
code.  But,
  if a 251 code is used, they MUST NOT assume that the client =
will actually
  update address information or even return that information to =
the user.

Alternately,

* Servers MAY reject or bounce messages when they are not =
deliverable when
  addressed.  When they do so, they MAY either provide =
address-updating
  information with a 551 code, or may reject the message as =
undeliverable
  with a 550 code and no address-specific information.  But, if =
a 251 code
  is used, they MUST NOT assume that the client will actually =
update
  address information or even return that information to the =
user.

SMTP server implementations that support the 251 and/or 551 =
reply codes are
strongly encouraged to provide configuration mechanisms so that =
sites which
conclude that they would undesirably disclose information can =
disable or
restrict their use.

----

Add new section 7.6 and renumber existing one to 7.7:

7.6 Information Disclosure in Message Forwarding

As discussed in section 3.4, use of the 251 or 551 reply codes =
to identify
the replacement address associated with a mailbox may =
inadvertently
disclose sensitive information.  Sites that are concerned about =
those
issues should ensure that they select and configure servers =
appropriately.

----

Remove "deprecated" reference to 251 and 551 in section 4.2.

Remove new section F.7.
--==========989813775==========--