idnits 2.17.1 draft-sam-smtp-redirects-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5321, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5321, updated by this document, for RFC5378 checks: 2005-07-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (9 July 2020) is 1386 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3463' is defined on line 236, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Sam 3 Internet-Draft 9 July 2020 4 Updates: 5321 (if approved) 5 Intended status: Standards Track 6 Expires: 10 January 2021 8 Forced Redirects in SMTP 9 draft-sam-smtp-redirects-00 11 Abstract 13 This document specifies two new response codes in the SMTP protocol 14 that relate to the redirection of emails meant for one email address 15 to another mail server/email address. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 10 January 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Problems with using 551 response code . . . . . . . . . . . . 3 53 3. The 557 and 558 response codes . . . . . . . . . . . . . . . 3 54 3.1. The 557/X.2.7 Response Code . . . . . . . . . . . . . . . 4 55 3.2. The 558/X.2.8 Response Code . . . . . . . . . . . . . . . 5 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 6.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 In todays digital world, email is the primary way of communication 66 for almost all Internet users. On the internet, there are many 67 services and accounts that require the use of a email address for 68 password recovery, etc. Changing a email address while "letting go" 69 of the old one can be very difficult. For the most part there 70 already is a solution: People trying to switch from one provider to 71 another have to "forward" email from their old mailbox to their new 72 one. 74 This system presents some problems. First off, the forwarded emails 75 are still going through the original mail server. w `While some may 76 like the system of silent fowarding (for example; having a support 77 email that goes to a random employee in the support department), some 78 may want to directly give their new address to people sending them 79 mail. If someone switched their email address to prevent their 80 emails from being processed or "seen" by the original mail server, 81 forwarding would be insufficient. In addition, mail server admins 82 may not want to deal with the extra bandwidth/CPU time required to 83 forward/relay emails to another server. The 2nd problem is that the 84 new email address doesn't automatically get updated with all of the 85 accounts or internet services the owner of the email address may 86 have, meaning that many entities wouldn't have any record of the new 87 email and would continue to send emails to the old email. Changing 88 the email address for each service a person has signed up with is 89 nearly impossible, and there are bound to be some that a person would 90 forget to change. To remedy this some opt to send an automated reply 91 email with their new email address to anyone that emails them; but 92 this system is not standardized and most automated systems fail to 93 recognize a email like this. This document aims to fix these 94 problems by introducing two new reply codes to be used in SMTP 95 sessions. 97 1.1. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119. 103 A email is known as "hard-linked" if the mail server is using the 104 557/558 reply codes to redirect mail to another email address. 106 The term "sending MTA" or "sending mail server" means any networked 107 device that tries to send mail to an email address/server, while the 108 term "receiving MTA" or "receiving mail server" is any networked 109 device that is receiving mail from a sending MTA. 111 A "email address" is a valid forward-path as defined in [RFC5321]. 113 A email is known as "hard-linked" if the mail server is using the 114 557/558 reply codes to redirect mail to another email address. 116 The email given in the 557/558 response code is defined as the "new" 117 email address. 119 2. Problems with using 551 response code 121 The problem with "reclaiming" the 551 response code is that it is now 122 being used for anything from incorrect authentication issues to a 123 response given to when the server is requested to act as an open 124 relay. This document mandates that any sending MTA that understands 125 the 557/558 response codes MUST make an attempt to resend the email 126 to the address given in the 557/558 response. In addition, any 127 response with a 557/558 code MUST include an additional email 128 address. Whether or not the forward-path is required to be included 129 in the 551 response code is unclear in previous RFCs. 131 3. The 557 and 558 response codes 133 The 557 and 558 codes are newly created response codes that are used 134 to "hard-link" email addresses. They both work by responding to a 135 SMTP request with the new email address. 137 Think of these response codes as a "forced" 551 response; on 138 receiving the 557 or 558 response, the sending mail server MUST try 139 to attempt delivery to the new address. This is what makes it 140 different from the 551 response code; most mail clients today just 141 regard 551 as a "failed send". When a email address is "hard-linked" 142 to a new one, the original email should be treated as if it was a 143 invalid/inactive/undeliverable email. However, Clients are still not 144 obligated to update any records as a result of a 557/558. 146 Servers now have multiple options when it comes to forwarding mail: 147 acknowledge forwarding with the 251 response code, forward silently 148 with the 250 code (what most servers do today), mark message as 149 undeliverable with 550/551, or use the 557/558 response codes. Like 150 with response code 551, receiving MTAs returning a 557/558 MUST NOT 151 assume that the client/sending MTA will update any records; but they 152 can assume that they will deliver it to the email specified in the 153 response. 155 3.1. The 557/X.2.7 Response Code 157 This code should be used when a mailbox has permanently moved to a 158 different email address. The function of this code is similar to the 159 HTTP 301 response code. This code is used to indicate that the owner 160 of the mailbox in question has permanently changed their email 161 address to one specified in the error response. When a sending mail 162 client receives this error code, they should send the intended email 163 to the email address specified in the response if they want the email 164 to be delivered. Since this is a permanent change, if the sending 165 MTA (mail transfer agent) is part of a larger system that keeps 166 tracks of emails (for example: a website/app that keeps emails for 167 password recovery), then the record SHOULD be updated (but is never 168 obligated to) hold the new email instead of the old email. If a user 169 emails another person and the receiving mail server returns a 557 170 code, then the server SHOULD notify the user about the new email 171 address. 173 Here is a sample session between two mail servers to showcase the 557 174 response code. 176 S: 220 smtp.example.com smtp service ready 177 C: HELO mail.example.net 178 S: 250 mail.example.net, I'm happy that you came around today 179 C: MAIL FROM: 180 S: 250 ok 181 C: RCPT TO: 182 S: 250 ok 183 C: RCPT TO: 184 S: 557 mailbox has moved to (X.2.7) 186 Client then connects to mail.example.org. 188 The server MUST include the new email address for mail to be 189 redirected to in the 557 response. It MUST NOT include any other 190 email addresses in the response. 192 3.2. The 558/X.2.8 Response Code 194 This code should be used when a mailbox has TEMPORARILY moved to a 195 different email address, which is similar to the 307 response code in 196 HTTP. This code should be used to indicate that the owner of the 197 mailbox has temporarily moved to a new email address. The reaction 198 to this code is similar to the 557 response code; MTAs should attempt 199 delivery to the new address. However, this code implies that the 200 owner of the email address will remove the "hard-link" at some point, 201 so any services keeping track of emails SHOULD NOT update the old 202 email in their records. 204 Like the 557 reply code, the response MUST include the new email 205 address in the response and MUST NOT include any other email address, 206 and the sending MTA MUST NOT make any attempt to send the email 207 through the old email server. 209 4. Security Considerations 211 A man in the middle/DNS hijack of a email server could return the 557 212 return code when an attempt is made to send mail to any email address 213 on the hijacked server. Thus, mail clients should be sure that they 214 are connecting to the right server. (a DNS/Man in the middle attack 215 would still allow emails to be "intercepted" if the servers are using 216 plain text and forwarding is in place) 218 5. IANA Considerations 220 IANA should add the following to the "SMTP Enhanced Status Code" 221 registry: 223 * Add 557/X.2.7 "Permanently Moved" response code 225 * Add 558/X.2.8 "Temporarily Moved" response code 227 6. References 229 6.1. Normative References 231 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 232 October 2008, . 234 6.2. Informative References 236 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 237 January 2003, . 239 Author's Address 241 Ekow Sam 243 Email: winshell64@gmail.com