Allow managing "changed" email addresses for SMTP 551 responses

[rimas-kudelis]

The SMTP standard has specified a separate response code which may be used when an email address to which a message is attempted to be delivered has changed and a different address should be used. That code is 551, and a suggested message is "User not local; please try <forward-path>".

Sadly, the standard does not specify what exactly the sender should do upon receiving this error code. Instead, it says the server [...] MUST NOT assume that the client will actually update address information or even return that information to the user[.] upon receiving that error code.

However, I propose that we add means to manage such addresses and properly report them to the sending servers.

Rationale

Some reasons why I want to use this functionality (and why I think it may be useful to others) are listed in this StackOverflow thread from 2015. With the "transparent" forwards that we have now:

1. It becomes more difficult to notify the client of a delivery failure
2. If the forwarded message was spam, it's the forwarding server that may end up being blacklisted and not the server that the message originated from ~(I suspect that this is the reason why my own server is currently blacklisted)~.
3. Similarly, when attempting to forward a message, the destination server will consult blacklists with forwarding server's IP instead of the original sender's IP.

But that's not all. I think a couple more points may be added to this list nowadays:

4. If the original message comes from an address in a domain with a strict SPF policy, the forwarded message might be considered as not aligned to the policy.
5. Similarly, I suspect that forwarding a message originating from a DKIM-enabled domain may also invalidate its DKIM signatures (I haven't really checked that myself, but I suspect this might be the case since at least my own emails become "DKIM not aligned" after being forwarded to another mailbox by outlook.com) (Edit: this actually depends on how SPF signing is configured in the MTA).

Implementation details

I see two ways how we could do this:

1. either add a new user type (in addition to the currently defined local, alias, catch, fail, piped, admin and site types). This would require:
   • a small DB schema change
   • a new menu item, management form and listing page
   • some additions to our Exim config files
2. or change our treatment of the current fail type: allow to optionally specify a "new" email address and if it is specified, fail with code 551 and that email address. We could reuse the forward database field for the address, so this would only require:
   • an update to the :fail: management form and listing page
   • some additions to our Exim config files

Option 1. seems perhaps a bit cleaner, but option 2. looks good as well, considering that 551 should most likely be seen as a fail code at the moment, and it will probably stay that way. Edit: actually, I think I'm in favor of option 2.

[Udera]

Do you know how such mails are handled in general? RFC just says the sender server either forwards the mail to the new address or returns an error message to the sender (https://tools.ietf.org/html/rfc821#page-7).

[rimas-kudelis]

I believe in most cases the rejection is just reported as usual, with the original message quoted. Here's what Gmail does, for example: If you click on the three dots at the bottom, you can see the original email quoted.