idnits 2.17.1 draft-ietf-sieve-refuse-reject-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 492. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 575 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 2006) is 6524 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: 'KEYWORDS' is defined on line 394, but no explicit reference was found in the text -- No information found for draft-ietf-sieve-3028bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SIEVE' ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) ** Downref: Normative reference to an Informational RFC: RFC 2033 (ref. 'LMTP') ** Obsolete normative reference: RFC 2298 (ref. 'MDN') (Obsoleted by RFC 3798) -- No information found for draft-ietf-sieve-vacation-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'VACATION' -- No information found for draft-ietf-sieve-spamtestbis-XX - is the name correct? -- No information found for draft-melnikov-smtp-lang-XX - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Elvey 2 Document: draft-ietf-sieve-refuse-reject-03 The Elvey Partnership, 3 LLC 4 Expires: December 2006 A. Melnikov 5 Isode Ltd 6 June 2006 8 The SIEVE mail filtering language - reject extension 9 draft-ietf-sieve-refuse-reject-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 A revised version of this draft document will be submitted to the 35 RFC editor as a Proposed Standard for the Internet Community. 36 Discussion and suggestions for improvement are requested. 37 Distribution of this draft is unlimited. 39 Abstract 41 This memo defines the SIEVE mail filtering language (RFC 42 <<3028bis>>) "reject" extension. 44 A Joe-job is a spam run forged to appear as though it came from an 45 innocent party, who is then generally flooded by the bounces, 46 Message Disposition Notifications (MDNs) and messages with 47 complaints. The original Sieve "reject" action defined in RFC 3028 48 required use of MDNs for rejecting messages, thus contributing to 49 the flood of Joe-job spam to victims of Joe-jobs. This document 50 updates definition of "reject" to require rejecting messages during 51 the SMTP transaction (instead of accepting them and then sending 52 MDNs back to the alleged sender) wherever possible, thereby 53 reducing the problem. 55 Table of Contents 57 1. Introduction 2 58 2. Conventions Used in this Document 3 59 3. SIEVE "reject" extension 3 60 3.1 Action reject 3 61 3.2 "reject" compatibility with other actions 7 62 4. Security Considerations 7 63 5. IANA Considerations 7 64 5.1 reject extension registration 7 65 5.2 refuse extension registration 8 66 6. References 8 67 6.1 Normative References 8 68 6.2 Informative References 8 69 7. Acknowledgments 9 70 8. Author's Addresses 9 71 9. Intellectual Property Rights Statement 9 72 10. Full Copyright Statement 10 73 11. Changes from RFC 3028 11 74 12. Change Log 11 76 1. Introduction 78 The SIEVE mail filtering language [SIEVE] "reject" action defined 79 in RFC 3028 only allowed users to refuse delivery of a message by 80 sending an [MDN]. 82 This document updates definition of the "reject" action to permit 83 users to handle unwanted email in a way that is sometimes 84 preferable to the existing 'discard' and the original 'reject' 85 capabilities. When a spam-detection system suspects a message is 86 spam, but isn't certain, discarding the email is considered too 87 risky for some users, for example, those who receive sales leads by 88 email. They are willing to use the reject command. Users are 89 willing to reject but not discard because the sender of an email 90 incorrectly marked as spam will receive a notification that the 91 email was refused, and will likely try again to contact the 92 intended recipient, perhaps via another method of communication. 93 Unfortunately, this usage is problematic, because in the usual 94 case, the email is indeed spam, and the alleged sender to whom an 95 MDN caused by the reject will be sent will often be an innocent Joe- 96 job victim. The updated "reject" is less likely to result in email 97 to an innocent victim, because it requires that an implemention 98 refuse to accept an email for delivery instead of accepting it and 99 then sending an MDN wherever possible. Much spam is sent through 100 open proxies, so SMTP level refusal reduces Joe-job bounces (AKA 101 backscatter) resulting from usage of MDNs. The updated "reject" 102 will also reduce Joe-jobs caused by virus self-propagation via 103 emails with false sender information. SMTP level refusal helps to 104 prevent the blacklisting of sources of backscatter and conserve 105 bandwidth, by reducing the number of MDNs sent. Further discussion 106 highlighting the risks of generating MDNs and the benefits of 107 protocol level refusal can be found in [Joe-DoS]. 109 2. Conventions Used in this Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 113 this document are to be interpreted as described in RFC 2119. 115 Conventions for notations are as in [SIEVE] section 1.1. 117 This document does not attempt to define what exactly constitutes a 118 spam or virus containing email or how it should be identified. 120 3. SIEVE "reject" extension 122 SIEVE implementations that implement the "reject" action must use 123 the "reject" capability string. 125 3.1 Action reject 127 Usage: reject 129 The "reject" action cancels the implicit keep and refuses delivery 130 of a message. The reason string is a UTF-8 [UTF-8] string 131 specifying the reason for refusal. How message is refused depends 132 on capabilities of mail component (MUA, MDA or MTA) executing the 133 Sieve script. The Sieve interpreter must do one of the following 134 actions, as detailed by the following priority table (items listed 135 earlier take precedence). Note that if action can not be taken or 136 fails, the interpreter should try the next item in the list: 138 1. If message return-path (MAIL FROM) is empty the message SHOULD 139 be accepted and discarded. 140 2. If a "reject" implementation performs a return-path verification 141 and it clearly indicates that the message has a forged return-path, 142 the implementation need not refuse mail delivery, but rather MAY 143 accept and discard it. 144 3. Message delivery is refused by sending 5XX response code over 145 SMTP [SMTP] or LMTP [LMTP]. See section 3.1.1 for more details. 146 4. Message delivery is refused by sending a non delivery report 147 (DSN [DSN]). See section 3.1.2 for more details. 148 5. Message delivery is refused by sending a message disposition 149 notification report (MDN). See section 3.1.3 for more details. 151 3.1.1 Rejecting messages at SMTP/LMTP protocol level 153 Sieve implementations that are able to reject messages at SMTP/LMTP 154 level SHOULD use the 550 response code. Note that if a message is 155 arriving over SMTP and has multiple recipients, some of which have 156 accepted the message, or the Sieve implementation is part of an 157 MUA, section 3.1.2 and section 3.1.3 define how to reject such a 158 message. 160 Note that SMTP [SMTP] doesn't allow for non-ASCII characters in 161 SMTP response text. If non-ASCII characters appear in the "reason" 162 string, they can be sent if and only if the client and the server 163 use an SMTP extension that allows for transmission of non-ASCII 164 reply text. (One example of such SMTP extension is described in 165 [UTF8-RESP].) In the absence of such SMTP extension, Sieve engine 166 MUST replace any reason string containing non-ASCII characters 167 with an implementation defined ASCII-only string. Implementations 168 SHOULD notify user that such replacement took place. 169 Users that don't like this behavior should consider using 170 "reject :exacttext" as described in Section 3.2, if available. 172 If the "reason" string consist of multiple CRLF separated lines, 173 than the reason text MUST be 174 returned as a multiline SMTP/LMTP response, per [SMTP], section 175 4.2.1. Any line MUST NOT exceed the SMTP limit on the maximal line 176 length. To make the reason string conform to any such limits the 177 server MAY insert CRLFs and turn the response into a multiline 178 response. 180 In the following script (which assumes support for the spamtest 181 [SPAMTEST] and fileinto extensions), messages that test highly 182 positive for spam are refused. 184 Example: 185 require ["reject", "spamtest", 186 "comparator-i;ascii-numeric", "fileinto"]; 188 if spamtest :value "ge" :comparator "i;ascii-numeric" "6" { 189 reject text: 190 AntiSpam engine thinks your message is spam. 191 It is therefore being refused. 192 Please call 1-900-PAY-US if you want to reach us. 193 . 194 ; 195 } elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" { 196 fileinto "Suspect"; 197 } 199 The following excerpt from an SMTP session shows it in action. 200 ... 201 C: DATA 202 S: 354 Send message, ending in CRLF.CRLF. 203 ... 204 C: . 205 S: 550-AntiSpam engine thinks your message is spam. 206 S: 550-It is therefore being refused. 207 S: 550 Please call 1-900-PAY-US if you want to reach us. 209 If the SMTP/LMTP server supports RFC 2034 [ENHANCED-CODES] it MUST 210 prepend an appropriate Enhanced Error Code to the "reason" text. 211 Enhanced Error code 5.7.1 or a more generic 5.7.0 are RECOMMENDED. 212 With Enhanced Error Code the response to DATA command in the SMTP 213 example below will look like: 215 S: 550-5.7.1 AntiSpam engine thinks your message is spam. 216 S: 550-5.7.1 It is therefore being refused. 217 S: 550 5.7.1 Please call 1-900-PAY-US if you want to reach us. 219 if the server selected "5.7.1" as appropriate. 221 If a Sieve implementation that supports "reject" doesn't wish to 222 immediately disclose the reason for rejection (for example that it 223 detected spam), it may delay immediate sending the 550 error code 224 by sending a 4XX error code on the first attempt to receive the 225 message. 227 3.1.2 Rejecting message by sending DSN 229 If the implementation receives a message via SMTP that has more 230 than one RCPT TO that has been accepted by the server, and at least 231 one but not all of them are refusing delivery (whether the refusal 232 is caused by execution of a Sieve "reject" or for another reason). 233 In this case, the server MUST accept the message and generate DSNs 234 for all recipients that are refusing it. Note that this exception 235 does not apply to LMTP, as LMTP is able to reject messages on a per- 236 recipient basis. 238 3.1.3 Rejecting message by sending MDN 240 When Sieve engine is running inside MUA it has no ability to reject 241 the message before it was delivered, as the message is already 242 delivered. In this case the client should send a Message 243 Disposition Notification [MDN] back to the sender. It resends the 244 message to the sender as specified in the Return-Path header field, 245 wrapping it in a "reject" form, noting that it was rejected by the 246 recipient. 247 MTAs and MDAs SHOULD NOT implement "reject" by sending MDNs, they 248 SHOULD reject at protocol level as described in section 3.1.1. 249 In the following script, a message is rejected and returned to the 250 sender. 252 Example: 253 require ["reject"]; 255 if header :contains "from" "coyote@desert.example.org" 256 { 257 reject text: 258 I am not taking mail from you, and I don't 259 want your birdseed, either!" 260 . 261 ; 262 } 264 A reject message MUST take the form of a failure MDN as specified 265 by [MDN]. The human-readable portion of the message, the first 266 component of the MDN, contains the human readable message 267 describing the error, and it SHOULD contain additional text 268 alerting the original sender that mail was refused by a filter. 269 This part of the MDN might appear as follows: 271 ------------------------------------------------------------ 272 The message was refused by the recipient's mail filtering program. 273 The reason 274 given was as follows: 276 I am not taking mail from you, and I don't want your birdseed, 277 either! 278 ------------------------------------------------------------ 280 The MDN action-value field as defined in the MDN specification MUST 281 be "deleted" and MUST have the MDN-sent-automatically and automatic- 282 action modes set. 284 3.2 :exacttext optional argument to reject action 286 SIEVE implementations that implement the :exacttext optional argument 287 to the "reject" action must advertise "rejectexact" capability in 288 addition to the "reject" capability described above. 290 The :exacttext argument affects how reject processing described in 291 section 3.1.1 is performed. When this argument is present, SMTP 292 client and server don't support an SMTP extension that allows for 293 transmission of non-ASCII reply text and there is non-ASCII text 294 in the reason string, then the reason string MUST NOT be replaced 295 with an implementation defined ASCII-only string as defined in 3.1.1. 296 Instead, Sieve engine MUST try to generate DSN, in order to preserve 297 the exact text specified in the reason string. 299 Example: 300 require ["reject", "rejectexact]; 302 if size :over 100K { 303 reject :exacttext text: 304 Your message is to big. If you want to send me a big attachement, 305 put it on a public web site and send me an URL. 306 . 307 ; 308 } 310 <> 312 NOTE: The :exacttext optional argument doesn't affect reject, if 313 Sieve engine is running in MUA, or if Sieve engine is running in 314 MTA/MDA, but it also supports an SMTP/LMTP extension for sending 315 UTF-8 responses. 317 3.3 "reject" compatibility with other actions 319 A "reject" action cancels the implicit keep. 321 Implementations MUST prohibit the execution of more than one reject 322 in a SIEVE script. "Reject" is also incompatible with the 323 "vacation" [VACATION] extensions. 325 Implementations MUST prohibit the execution of more than one reject 326 in a SIEVE script. "Reject" MUST be incompatible with the "vacation" 327 [VACATION] action. Implementations SHOULD prohibit the use of 328 "reject" with actions that cause mail delivery, such as "keep", 329 "fileinto", "redirect". <> 330 Making "reject" compatible with actions that cause mail delivery 331 violates RFC 2821 principal that a message is either deliver or 332 bounced back to the sender. So bouncing message back (rejecting) 333 and delivering it will make the sender believe that the message was 334 not delivered. 335 However there are existing laws requiring certain organizations to 336 archive all received messages, even the rejected ones. Also, it can be 337 quite convenient to save copies of rejected messages for later 338 analysis. 340 Any action that would modify the message body will not have effect 341 on the body of any message refused by "reject" using the 550 SMTP 342 response code and MUST NOT have any effect on context of generated 343 DSN/MDNs. 345 4. Security Considerations 347 The Introduction section talks about why rejecting messages before 348 delivery is better then accepting and bouncing them. 350 Security issues associated with mail auto-responders are fully 351 discussed in the security consideration section of [RFC3834]. This 352 document is believed not to introduce any additional security 353 considerations in this general area. 355 The "reject" extension does not raise any other security 356 considerations that are not already present in the base [SIEVE] 357 protocol, and these issues are discussed in [SIEVE]. 359 5. IANA Considerations 361 The following section provides the IANA registrations for the Sieve 362 extensions specified in this document: 364 5.1 reject extension registration 366 IANA is requested to update the registration for the SIEVE "reject" 367 extension to point to this document. 368 IANA is also requested to update Tim Showalter's email address to 369 be 370 tjs@psaux.com 372 5.2 refuse extension registration 374 IANA is requested to remove registration of the refuse extension. 375 <> 377 5.3 rejectexact extension registration 379 IANA is requested to add the following registration to the list of 380 Sieve extensions: 382 Capability name: rejectexact 383 Description: adds the ':exacttext' optional argument to the 384 reject action, which instructs Sieve engine to 385 generate Delivery Status Notifications if rejection 386 reason string contains non-ASCII text. 387 RFC number: this RFC (Sieve base spec) 388 Contact address: The Sieve discussion list 390 6. References 392 6.1 Normative References 394 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", RFC 2119, March 1997. 397 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 398 Language", Work-in-progress, draft-ietf-sieve-3028bis-XX.txt 400 [SMTP] Klensin, J. (Editor), "Simple Mail Transfer Protocol", AT&T 401 Laboratories, RFC 2821, April 2001. 403 [LMTP] Myers, J., "Local Mail Transfer Protocol", Carnegie-Mellon 404 University, RFC 2033, October 1996. 406 [DSN] Moore , K., Vaudreuil, G., "An Extensible Message Format for 407 Delivery Status Notifications", University of Tennessee, Lucent 408 Technologies, RFC 3464, January 2003. 410 [MDN] Fajman, R., "An Extensible Message Format for Message 411 Disposition Notifications", National Institutes of Health, RFC 412 2298, March 1998. 414 [ENHANCED-CODES] Freed, N., "SMTP Service Extension for Returning 415 Enhanced Error Codes", Innosoft, RFC 2034, October 1996. 417 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 418 RFC 3629, November 2003. 420 [VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: 421 Vacation Extension", work in progress, draft-ietf-sieve-vacation-XX.txt. 423 6.2 Informative References 425 [Joe-DoS] Stefan Frei, Ivo Silvestri, Gunter Ollmann, "Mail Non 426 Delivery Message DDoS Attacks", 5 April 2004", 427 . 429 [SPAMTEST] Daboo, C., "SIEVE Email Filtering: Spamtest and 430 Virustest Extensions", work in progress, draft-ietf-sieve- 431 spamtestbis-XX.txt 432 <> 435 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 436 Electronic Mail", RFC 3834, August 2004. 438 [UTF8-RESP] A. Melnikov (Ed.), "SMTP Language Extension", 439 work in progress, draft-melnikov-smtp-lang-XX.txt 441 7. Acknowledgments 443 Thanks to Ned Freed, Cyrus Daboo, Arnt Gulbrandsen, Kristin Hubner, 444 Mark E. Mallett, Philip Guenther and Michael Haardt for comments 445 and corrections. 447 The authors gratefully acknowledge the extensive work of Tim 448 Showalter as the author of the RFC 3028, which originally defined 449 the "reject" action. 451 8. Author's Addresses 453 Matthew Elvey 454 The Elvey Partnership, LLC 455 3042 Sacramento-ietf St Ste 04 456 San Francisco, CA 457 U.S.A. 459 Email: sieve3@matthew.elvey.com 461 Alexey Melnikov 462 Isode Limited 463 5 Castle Business Village 464 36 Station Road 465 Hampton, Middlesex, TW12 2BX 466 UK 468 Email: Alexey.Melnikov@isode.com 470 9. Intellectual Property Rights Statement 472 The IETF takes no position regarding the validity or scope of any 473 Intellectual Property Rights or other rights that might be claimed 474 to pertain to the implementation or use of the technology described 475 in this document or the extent to which any license under such 476 rights might or might not be available; nor does it represent that 477 it has made any independent effort to identify any such rights. 478 Information on the procedures with respect to rights in RFC 479 documents can be found in BCP 78 and BCP 79. 481 Copies of IPR disclosures made to the IETF Secretariat and any 482 assurances of licenses to be made available, or the result of an 483 attempt made to obtain a general license or permission for the use 484 of such proprietary rights by implementers or users of this 485 specification can be obtained from the IETF on-line IPR repository 486 at http://www.ietf.org/ipr. 488 The IETF invites any interested party to bring to its attention any 489 copyrights, patents or patent applications, or other proprietary 490 rights that may cover technology that may be required to implement 491 this standard. Please address the information to the IETF at ietf- 492 ipr@ietf.org. 494 10. Full Copyright Statement 496 Copyright (C) The Internet Society (2006). 498 This document is subject to the rights, licenses and restrictions 499 contained in BCP 78, and except as set forth therein, the authors 500 retain all their rights. 502 This document and the information contained herein are provided on 503 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 504 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 505 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 506 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 507 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 508 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 509 PARTICULAR PURPOSE. 511 Acknowledgement 513 Funding for the RFC Editor function is currently provided by the 514 Internet Society. 516 11. Changes from RFC 3028 518 Clarified that the "reject" action cancels the implicit keep. 519 Extended list of allowable actions on reject to include protocol 520 level message rejection and generation of DSNs. 522 12. Change Log 524 <> 527 00 First formal draft. 528 01 Explicit RFC 2034 support, disallow "refuse" in MUAs, typos 529 corrected, clarifications, etc. 530 02 Many insubstantial editorial changes (mostly rewording text for 531 readability). Added text regarding non-ASCII characters in the refuse 532 "reason" string. Added an exception allowing return-path forgery to 533 justify discarding a message. 534 03 (Renamed to be SIEVE WG 00) - Updated boilerplate, added reject 535 action from the base spec, acknowledged Tim as the author of 536 "reject". 537 04 (SIEVE WG 01) Based on WGLC feedback, the refuse and the reject 538 actions were merged into a single action called reject. Text 539 reorganized as the result. Typos and examples corrected. Updated 540 IANA registration and Security Considerations sections. 541 05 (SIEVE WG 02) Copied some security considerations from Vacation 542 draft. Clarified that the "reason" string is in UTF-8. Clarified 543 interaction with "editheader" extension. Added text about sending 544 of 4XX instead of 550. Corrected typos in several examples. 545 06 (SIEVE WG 03) Explicitly list all actions incompable with reject. 546 Added two paragraphs explaining why reject SHOULD (as opposed to 547 MUST/MAY) be incompatible with them. Clarified that if the reason 548 string contains non-ASCII and rejection over protocol is possible, 549 then the reason string MUST be replaced with an implementations 550 defined ASCII-only string. Added :exacttext optional argument that 551 preserves UTF-8 reason string by forcing generation of DSN.