[Docs] [txt|pdf] [Tracker] [Email] [Nits]



Internet Engineering Task Force                                   E. Sam
Internet-Draft                                               9 July 2020
Updates: 5321 (if approved)
Intended status: Standards Track
Expires: 10 January 2021


                        Forced Redirects in SMTP
                      draft-sam-smtp-redirects-00

Abstract

   This document specifies two new response codes in the SMTP protocol
   that relate to the redirection of emails meant for one email address
   to another mail server/email address.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 10 January 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.





Sam                      Expires 10 January 2021                [Page 1]


Internet-Draft          Forced Redirects in SMTP               July 2020


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problems with using 551 response code . . . . . . . . . . . .   3
   3.  The 557 and 558 response codes  . . . . . . . . . . . . . . .   3
     3.1.  The 557/X.2.7 Response Code . . . . . . . . . . . . . . .   4
     3.2.  The 558/X.2.8 Response Code . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In todays digital world, email is the primary way of communication
   for almost all Internet users.  On the internet, there are many
   services and accounts that require the use of a email address for
   password recovery, etc.  Changing a email address while "letting go"
   of the old one can be very difficult.  For the most part there
   already is a solution: People trying to switch from one provider to
   another have to "forward" email from their old mailbox to their new
   one.

   This system presents some problems.  First off, the forwarded emails
   are still going through the original mail server. w `While some may
   like the system of silent fowarding (for example; having a support
   email that goes to a random employee in the support department), some
   may want to directly give their new address to people sending them
   mail.  If someone switched their email address to prevent their
   emails from being processed or "seen" by the original mail server,
   forwarding would be insufficient.  In addition, mail server admins
   may not want to deal with the extra bandwidth/CPU time required to
   forward/relay emails to another server.  The 2nd problem is that the
   new email address doesn't automatically get updated with all of the
   accounts or internet services the owner of the email address may
   have, meaning that many entities wouldn't have any record of the new
   email and would continue to send emails to the old email.  Changing
   the email address for each service a person has signed up with is
   nearly impossible, and there are bound to be some that a person would
   forget to change.  To remedy this some opt to send an automated reply
   email with their new email address to anyone that emails them; but
   this system is not standardized and most automated systems fail to
   recognize a email like this.  This document aims to fix these
   problems by introducing two new reply codes to be used in SMTP
   sessions.



Sam                      Expires 10 January 2021                [Page 2]


Internet-Draft          Forced Redirects in SMTP               July 2020


1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   A email is known as "hard-linked" if the mail server is using the
   557/558 reply codes to redirect mail to another email address.

   The term "sending MTA" or "sending mail server" means any networked
   device that tries to send mail to an email address/server, while the
   term "receiving MTA" or "receiving mail server" is any networked
   device that is receiving mail from a sending MTA.

   A "email address" is a valid forward-path as defined in [RFC5321].

   A email is known as "hard-linked" if the mail server is using the
   557/558 reply codes to redirect mail to another email address.

   The email given in the 557/558 response code is defined as the "new"
   email address.

2.  Problems with using 551 response code

   The problem with "reclaiming" the 551 response code is that it is now
   being used for anything from incorrect authentication issues to a
   response given to when the server is requested to act as an open
   relay.  This document mandates that any sending MTA that understands
   the 557/558 response codes MUST make an attempt to resend the email
   to the address given in the 557/558 response.  In addition, any
   response with a 557/558 code MUST include an additional email
   address.  Whether or not the forward-path is required to be included
   in the 551 response code is unclear in previous RFCs.

3.  The 557 and 558 response codes

   The 557 and 558 codes are newly created response codes that are used
   to "hard-link" email addresses.  They both work by responding to a
   SMTP request with the new email address.

   Think of these response codes as a "forced" 551 response; on
   receiving the 557 or 558 response, the sending mail server MUST try
   to attempt delivery to the new address.  This is what makes it
   different from the 551 response code; most mail clients today just
   regard 551 as a "failed send".  When a email address is "hard-linked"
   to a new one, the original email should be treated as if it was a
   invalid/inactive/undeliverable email.  However, Clients are still not
   obligated to update any records as a result of a 557/558.



Sam                      Expires 10 January 2021                [Page 3]


Internet-Draft          Forced Redirects in SMTP               July 2020


   Servers now have multiple options when it comes to forwarding mail:
   acknowledge forwarding with the 251 response code, forward silently
   with the 250 code (what most servers do today), mark message as
   undeliverable with 550/551, or use the 557/558 response codes.  Like
   with response code 551, receiving MTAs returning a 557/558 MUST NOT
   assume that the client/sending MTA will update any records; but they
   can assume that they will deliver it to the email specified in the
   response.

3.1.  The 557/X.2.7 Response Code

   This code should be used when a mailbox has permanently moved to a
   different email address.  The function of this code is similar to the
   HTTP 301 response code.  This code is used to indicate that the owner
   of the mailbox in question has permanently changed their email
   address to one specified in the error response.  When a sending mail
   client receives this error code, they should send the intended email
   to the email address specified in the response if they want the email
   to be delivered.  Since this is a permanent change, if the sending
   MTA (mail transfer agent) is part of a larger system that keeps
   tracks of emails (for example: a website/app that keeps emails for
   password recovery), then the record SHOULD be updated (but is never
   obligated to) hold the new email instead of the old email.  If a user
   emails another person and the receiving mail server returns a 557
   code, then the server SHOULD notify the user about the new email
   address.

   Here is a sample session between two mail servers to showcase the 557
   response code.

   S: 220 smtp.example.com smtp service ready
   C: HELO mail.example.net
   S: 250 mail.example.net, I'm happy that you came around today
   C: MAIL FROM: <postmaster@example.net>
   S: 250 ok
   C: RCPT TO:<http@example.com>
   S: 250 ok
   C: RCPT TO:<gopher@example.com>
   S: 557 mailbox has moved to <mccahill@example.org> (X.2.7)

   Client then connects to mail.example.org.

   The server MUST include the new email address for mail to be
   redirected to in the 557 response.  It MUST NOT include any other
   email addresses in the response.






Sam                      Expires 10 January 2021                [Page 4]


Internet-Draft          Forced Redirects in SMTP               July 2020


3.2.  The 558/X.2.8 Response Code

   This code should be used when a mailbox has TEMPORARILY moved to a
   different email address, which is similar to the 307 response code in
   HTTP.  This code should be used to indicate that the owner of the
   mailbox has temporarily moved to a new email address.  The reaction
   to this code is similar to the 557 response code; MTAs should attempt
   delivery to the new address.  However, this code implies that the
   owner of the email address will remove the "hard-link" at some point,
   so any services keeping track of emails SHOULD NOT update the old
   email in their records.

   Like the 557 reply code, the response MUST include the new email
   address in the response and MUST NOT include any other email address,
   and the sending MTA MUST NOT make any attempt to send the email
   through the old email server.

4.  Security Considerations

   A man in the middle/DNS hijack of a email server could return the 557
   return code when an attempt is made to send mail to any email address
   on the hijacked server.  Thus, mail clients should be sure that they
   are connecting to the right server.  (a DNS/Man in the middle attack
   would still allow emails to be "intercepted" if the servers are using
   plain text and forwarding is in place)

5.  IANA Considerations

   IANA should add the following to the "SMTP Enhanced Status Code"
   registry:

   *  Add 557/X.2.7 "Permanently Moved" response code

   *  Add 558/X.2.8 "Temporarily Moved" response code

6.  References

6.1.  Normative References

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008, <https://www.rfc-editor.org/info/rfc5321>.

6.2.  Informative References

   [RFC3463]  Vaudreuil, G., "Enhanced Mail System Status Codes",
              January 2003, <https://www.rfc-editor.org/info/rfc3463>.





Sam                      Expires 10 January 2021                [Page 5]


Internet-Draft          Forced Redirects in SMTP               July 2020


Author's Address

   Ekow Sam

   Email: winshell64@gmail.com














































Sam                      Expires 10 January 2021                [Page 6]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/