Есть ли способ для SMTP-сервера ответить, что пользователь перешел на новый адрес?

Такие коды состояния есть для обоих

• пересылка (251 User not local; will forward to <forward-path>) и
• отклоняя (551 User not local; please try <forward-path>)

но они предназначены для почтовые пользовательские агенты (MUA), а не для других MTA.

В RFC 5321, 3.4 Пересылка для исправления или обновления адреса объясняет эти стандартные коды ответов, которые имеют способность сообщить отправителю новый адрес. Акцент мой.

Следовательно, механизмы "пересылки", описанные в разделе 3.2 RFC 821, и особенно 251 (исправленный пункт назначения) и 551 коды ответа от RCPT должны тщательно оцениваться разработчиками и, если они доступны, теми, кто настраивает системы (см. также Раздел 7.4).

В частности:

• Серверы МОГУТ пересылать сообщения, когда им известно об изменении адреса. Когда они это сделают, они МОГУТ либо предоставить информацию об обновлении адреса с помощью 251 код, или может пересылать "молча" и возвращать 250 код. Тем не мение, если 251 используется код, они НЕ ДОЛЖНЫ предполагать, что клиент действительно обновит адресную информацию или даже вернет эту информацию пользователю.

Альтернативно,

• Серверы МОГУТ отклонять сообщения или возвращать их как недоставленные, если они не могут быть доставлены точно по адресу. Когда они это делают, они МОГУТ либо предоставить информацию об обновлении адреса с помощью 551 код, или может отклонить сообщение как недоставленное с 550 код и никакой адресной информации. Тем не мение, если 551 код, они НЕ ДОЛЖНЫ предполагать, что клиент действительно обновит адресную информацию или даже вернет эту информацию пользователю.

Реальность такова, что адреса электронной почты на самом деле не обновляются MUA на основе этих кодов статуса, вероятно, потому, что их подлинность трудно доказать. Я тоже нигде не видел, чтобы эти коды ответов широко использовались.

Это также практические проблемы с автоматическим обновлением адресов электронной почты, а также пересылка:

• Если пользователь изменил адрес из-за того, что старый адрес получает много спама, было бы неразумно раскрывать новую контактную информацию. Это для личных адресов электронной почты.

• При использовании служебных адресов электронной почты вероятная причина изменения адреса заключается в том, что пользователь получил новую работу от другого работодателя.

  • Существует проблема с различением, адресовано ли электронное письмо человеку или его / ее бывшей должности в компании. Потребуется опубликовать два новых адреса, а с этими кодами ошибок это действительно невозможно, поскольку автоматическое обновление было бы невозможно без вмешательства человека.

  • Старому работодателю необязательно знать новый адрес. Кроме того, было бы неразумно указывать клиентам на этот новый адрес, поскольку это может указывать на их конкурента.

  • Обычно отправитель приходит к выводу, что человек там больше не работает, если письмо просто возвращается с 550 mailbox unavailable. Затем они будут искать в Google подходящий адрес для своего контакта.

Если вы хотите отличить почтовый ящик, который никогда не существовал, от почтового ящика, который когда-то существовал, но был удален, вы можете использовать, например, RFC 3463 расширенный код состояния X.1.6:

X.1.6 Целевой почтовый ящик перемещен, нет адреса для пересылки

Предоставленный адрес почтового ящика был когда-то действительным, но почта на этот адрес больше не принимается. Этот код полезен только при постоянных сбоях.

Наконец, как упоминалось в RFC 5321, 2.3.7:

Общая форма ответа - это числовой код завершения (указывающий на неудачу или успех), за которым обычно следует текстовая строка. Коды предназначены для использования программами, а текст обычно предназначен для пользователей.

Было бы разумно добавить понятное для человека объяснение, например

550 5.1.6 Joe Bloggs has retired. See example.com/contact for a new representative.