Subject: The 551/251 question

From: John C Klensin <[email-masked]>
Date: Fri, 07 Jul 2000 17:14:00 -0400

The consensus seems to be to deprecate both of these.  Proposed
text (last part of the 2nd (i.e., former last) paragraph of
section 3.4 and a new paragraph) follows.  Again, please speak
up only if you cannot live with this (and do so soon).

	described in section 3.2 of RFC 821, and especially the
	251 (corrected destination) reply code from RCPT are
	deprecated: While servers MAY quietly forward messages
	when they are aware of an address change, they SHOULD
	NOT provide address-updating information via a 251 code.
	
	Similar considerations apply to 551.  While an SMTP
	client that handles it only as a permanent failure
	message will presumably do the correct thing and route
	the message back to the user as undeliverable, the use
	of the code implies belief on the server's part that
	automatic address book updating will occur.  That
	expectation is unreasonable, since no, or virtually no,
	client SMTP systems in the contemporary Internet provide
	that service (it made much more sense when messages were
	sent directly from user processes to receiving SMTP
	systems).   Consequently, servers SHOULD NOT attempt to
	provide address-updating information via a 551 code.

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Jul 2000 21:23:03 -0400

I don't think the deprecation of 551/251 is justified.  The fact that
the service isn't widely implemented by servers today doesn't mean that
it's not a useful feature; rather, it might mean that we don't have
a good way to communicate this to user agents that might make use of it.

DSNs could easily provide such a mechanism to communicate changes of
address to senders.  Then you have the problem that DSNs containing 
such responses could easily be forged.  But SMTP also provides a means
of verification - just try to send a dummy message to the recipient
(directly to the recipient's MX) and you'll get back the same 551
code in response to RCPT.  

This seems so simple to do and so potentially useful that I really
hate to see 551 deprecated - it makes it that much harder to finish the job.

Keith

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 Jul 2000 14:30:48 +1000

Date:        Fri, 07 Jul 2000 17:14:00 -0400
    From:        John C Klensin <[email-masked]>
    Message-ID:  <917366236.962990040@P2>

  | The consensus seems to be to deprecate both of these.

Really?

  | 	Similar considerations apply to 551.  While an SMTP
  | 	client that handles it only as a permanent failure
  | 	message will presumably do the correct thing and route

"Presumably"?   Are there any known instances at all of a SMTP client
not treating 551 as a bounce?

  | 	the message back to the user as undeliverable, the use
  | 	of the code implies belief on the server's part that
  | 	automatic address book updating will occur.

Says who?   It allows it to occur, it no-where assumes that it
will occur.

  | 	Consequently, servers SHOULD NOT attempt to
  | 	provide address-updating information via a 551 code.

Even allowing all the assumptions, I don't see how that follows.
There's no indication of any reason at all for a server to not
send that reply code, the best you have done is provided a justification
for a server not sending it (ie: I don't need to bother with this, it
isn't really useful), not against it being sent (ie: I could easily
send a 551, but it might harm someone, so I won't).  To me that
is exactly a "MAY send" state.

551 is used today - and even understood by clients, not to do
address book updating, but just to give a more comprehensible
error message to the user.

Rather than "user unknown" or "mailbox does not exist" or something
like that, "551" allows clients to say "The user's e-mail address
has changed, the new address might be <...>", which is much nicer.

Please just leave 551.   Even 251 is harmless.

If we can't justify these, then we should probably just drop the
2nd and 3rd digits completely (still require them for compatability
but define them as 100% meaningless).  That is, mandate that clients
must not use anything but the first digit of the reply code.  I don't
think that would be the right solution - being able to gain some
extra insight into the cause of a problem is useful.

kre

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Jul 2000 13:21:22 -0400

--On Saturday, 08 July, 2000 14:30 +1000 Robert Elz
<[email-masked]> wrote:

>...

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

---

From: Keith Moore <[email-masked]>
Date: Sun, 09 Jul 2000 01:01:06 -0400

the new 552/251 text looks good to me.

thanks,

Keith

---

From: [email-masked] (Kai Henningsen)
Date: 09 Jul 2000 22:29:00 +0200

[email-masked] (John C Klensin)  wrote on 08.07.00 in <989808016.963062482@P2>:

> 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.

s/251/551/ here.

MfG Kai

---

From: Robert Elz <[email-masked]>
Date: Mon, 10 Jul 2000 13:22:10 +1000

Date:        Sun, 09 Jul 2000 01:01:06 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | the new 552/251 text looks good to me.

Yes, it would be fine.   I'm not sure that it really needs say anything
about what assumptions the server ought not be making about "address book"
updating, as I don't think it has ever made any sense (or could possibly)
for the server to assume anything of the kind.  But leaving it there as
positive reinforcement can't hurt.

kre