Re: [ietf-smtp] SMTP status codes 251 and 551

[John C Klensin <[e-mail]>]

--On Sunday, February 9, 2020 21:58 -0500 John R Levine
<[e-mail]> wrote:

> SMTP has had the 251 and 551 status codes for a long time,
> since RFC 788 in 1981.  The 251 code means (roughly) I'll
> accept this address but I'll forward it to <x>, and 551 means
> address rejected, send it to <x> instead. The idea is that the
> sending system should note the <x> address so in future it
> sends mail directly there.
> 
> Did anyone every actually implement these, and in particular
> the sender side to remember and redirect?  You don't have to
> tell me all the reasons it's a bad idea, many of which are
> described in the RFCs.  I'm just wondering whether this was
> ever real, or it just seemed like a good idea.

John,

If you ask me about how many implementations that are currently
active and in heavy use, I don't know, but 251 and 551 were part
of the same thinking that produced the VRFY (and, to a lesser
extent, EXPN) commands and were very widely implemented and
used, even more so as many institutions, especially academic
ones, shifted from [e-mail]
addressing to preferring [e-mail] addressing.  They
were especially important when  some institutions were willing
to forward or otherwise handle messages for a while to the new
jobs/ institutions of faculty and staff who had left but did not
want to have to do that indefinitely and hence wanted to notify
senders to update their address books.  IIR, there were even a
few MUAs around that would pick the information up and turn it
into a "do you want to update the address in your address book?"
questions to the users.

My very vague recollection is that even at least one of the
second-generation BITNET-Internet mail gateways supported 551
functionality.  

Now, in today's far more hostile world, there are, as you
suggest, many reasons why they, perhaps especially 251, are bad
ideas on the public Internet.  I would guess that
implementations that still support those codes and the
associated actions have configuration options to turn them off,
either globally or for mail send outside the organization or
enterprise and that "off" is the preferred default.  I can
actually see some advantages for organizations that divide up
their internal mail systems by laboratory or country (and
pressure to do the latter from privacy law differences) when
people make intra-company moves.   But, no, one cannot get rid
of them on the basis of "never implemented or deployed".

best,
   john