Closed ietf-svn-bot closed 2 years ago
@alexey.melnikov@isode.com changed title from Revisiting Quoted Strings
to G.9. Revisiting Quoted Strings
@alexey.melnikov@isode.com set component to smtp
@alexey.melnikov@isode.com commented
Which of the following are valid in the address local-parts?
"ab cd ef" "ab\ cd ef" ab\ cd ef "ab cd ef\"\"" "\a\b\ \c\c\ \e\f" "\ ab cd ef"
Similar questions for the following:
"\ \ \ \ \ " "\ " "" "\"\""
Which of the following are valid in the address local-parts?
"\ \ \ \ \ " "\ " "" "\"\""
@alexey.melnikov@isode.com commented
John Klensin suggested a possible resolution:
Clarify whether ""@example.com and/or " "@example.com and a few variations are valid, clarify that white space reduction MUST NOT be applied by intermediate systems, and then put a paragraph into the A/S that says that any mail administrators who allow those sorts of things as mailboxes on their system, whether it tries to canonicalize them or not, is looking for bad karma to descend upon them.
@alexey.melnikov@isode.com changed status from new
to assigned
@alexey.melnikov@isode.com set owner to alexey.melnikov@isode.com
@alexey.melnikov@isode.com commented
In Section "4.1.2. Command Argument Syntax", the 1st paragraph after the ABNF syntax reads:
While the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case- sensitive. For any purposes that require generating or comparing Local-parts (e.g., to specific mailbox names), all quoted forms MUST be treated as equivalent, and the sending system SHOULD transmit the form that uses the minimum quoting possible.
Suggestion to add to the end:
For example, the following 3 Local-parts are semantically equivalent and must compare equal: "ab cd ef", "ab\ cd ef" and "ab\ \cd ef". Similarly, "fred" and fred must compare equal. White space reduction MUST NOT be applied to Local-part by intermediate systems.
In Section "4.1.2. Command Argument Syntax", the 3rd paragraph after the ABNF:
Note that the backslash, "\", is a quote character, which is used to indicate that the next character is to be used literally (instead of its normal interpretation). For example, "Joe\,Smith" indicates a single nine-character user name string with the comma being the fourth character of that string.
Suggestion to move it before the 1st paragraph after the ABNF (so that it introduces \ escape character).
-11 added some examples to clarify Ned Freed's concerns, but there are some typos in them.
are still seen in examples (in -12), but this can be fixed by RFC Editor.
keyword_SMTP
owner:alexey.melnikov@isode.com
type_task
| by alexey.melnikov@isode.com4.1.2. Command Argument Syntax
While the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case- sensitive. For any purposes that require generating or comparing Local-parts (e.g., to specific mailbox names), all quoted forms MUST be treated as equivalent, and the sending system SHOULD transmit the form that uses the minimum quoting possible.
Recent discussions both in and out of the IETF have highlighted instances of non-compliance with the specification of a Local-part consisting of a Quoted-string, whether any content of QcontentSMTP that actually requires special treatment consists of qtextSMTP, quoted-pairSMTP, or both. Section 4.1.2 ends with a few paragraphs of warnings (essentially a partial applicability statement), the first of which cautions against cleverness with either Quoted-string or case sensitivity as a threat to interoperability.
The Quoted-string portion of that discussion has apparently been widely not read or ignored. Do we need to do something else? If we do an Applicability Statement, would it be useful to either reference the discussion in this document from there or to move the discussion there and reference it (normatively?) from here?
Issue migrated from trac:21 at 2022-01-31 12:35:06 +0000