There are such status codes for both
- forwarding (
251 User not local; will forward to <forward-path>) and
- rejecting (
551 User not local; please try <forward-path>)
but they are intended for the mail user agents (MUA), not for other MTAs.
The RFC 5321, 3.4 Forwarding for Address Correction or Updating explains these standard response codes that do have the ability to inform the sender about the new address. Emphasis is mine.
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 (see also Section 7.4).
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. However, 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 messages or return them as non-deliverable
when
they cannot be delivered precisely as 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. However, if a 551 code is
used, they MUST NOT assume that the client will actually update
address information or even return that information to the user.
The reality is that email addresses aren't really updated by the MUAs based on these status codes, probably because their authenticity has been hard to prove. I haven't seen these response codes widely in use anywhere, either.
There are also practical problems with automatic email address updates, as well as forwarding:
If a user has changed the address because the old address gets a lot of spam, it wouldn't be wise to disclose the new contact information. That's for personal email addresses.
With business email addresses the probable reason for address change is that the user has got a new job from another employer.
There's a problem to distinguish whether the email is addressed to the person or to his/her former position in the company. There would be a need to publish two new addresses, and that really can't be done with these error codes, as automatic update would be impossible without human desicion.
The old employer doesn't necessarily even know the new address. Furthermore, it might not be wise to point the clients to this new address, as it might point them towards a competitor.
Usually a sender will conclude that the person doesn't work there anymore, if the email just bounces with 550 mailbox unavailable. Then, they will Google for a suitable address for their contact.
If you want to distinguish a mailbox that never existed from a mailbox that once existed but has been removed, you could use e.g. RFC 3463 extended status code X.1.6:
X.1.6 Destination mailbox has moved, No forwarding address
The mailbox address provided was at one time valid, but mail is
no longer being accepted for that address. This code is only
useful for permanent failures.
Finally, as mentioned in RFC 5321, 2.3.7:
The general form of a reply is a numeric completion code
(indicating failure or success) usually followed by a text string.
The codes are for use by programs and the text is usually intended
for human users.
It would be wise to add a human readable explanation, e.g.
550 5.1.6 Joe Bloggs has retired. See example.com/contact for a new representative.
