email / idn-email: scope questions - 4.5.3.1 length limits and control / noncharacter codepoints

[vtushar06]

Two scope questions came up while adding idn-email tests. Both are about what the email / idn-email format should and should not check, and I would rather get a ruling than guess.

1. RFC 5321 section 4.5.3.1 length limits

The email format is the "Mailbox" ABNF (RFC 5321 section 4.1.2; RFC 6531 section 3.3 for idn-email). That grammar has no length limits. The 64-octet local part, 255-octet domain and 63-octet label limits live in section 4.5.3.1, which is about transport size limits, not the Mailbox grammar.

My reading is that format validation should follow the grammar and not enforce the 4.5.3.1 limits - a 65-octet local part would still be a valid email per section 4.1.2. Is that the intended scope, or should the suite test the 4.5.3.1 limits?

2. Control and noncharacter codepoints in the local part (idn-email)

RFC 6531 extends the local part with UTF8-non-ascii (any well-formed non-ASCII), and the "MUST NOT contain any of the ASCII graphics or control characters" clause only bars ASCII controls. By that text, a C1 control (U+0085) or a noncharacter (U+FFFF) is permitted in the local part.

RFC 6531 errata 4996 (Held) questions whether that clause was meant to exclude the 128-255 range too, so the wording is not fully settled. Should idn-email treat a C1 control / noncharacter in the local part as valid (the literal grammar reading) or invalid?

• RFC 5321 (sections 4.1.2 and 4.5.3.1): https://www.rfc-editor.org/rfc/rfc5321
• RFC 6531 section 3.3: https://www.rfc-editor.org/rfc/rfc6531#section-3.3
• RFC 6531 errata 4996: https://www.rfc-editor.org/errata/eid4996

[vtushar06]

@jviotti needs discussion over this.

[RishiByte]

After reading RFC 5321 §4.1.2 and §4.5.3.1, I lean toward treating the length limits as transport constraints rather than mailbox syntax constraints. The Mailbox ABNF itself doesn't encode those limits, so a 65-octet local part appears syntactically valid even if it may exceed SMTP transport requirements.

For idn-email, I'd favor following the literal RFC 6531 grammar unless there is explicit consensus or errata clarifying otherwise. That would imply UTF8-non-ascii code points are allowed in the local part, including cases not explicitly excluded by the grammar.

That said, consistency with existing validator implementations may also be worth considering. Do we want the test suite to verify strict RFC grammar compliance, or common validation behavior across implementations?

[jdesrosiers]

1. RFC 5321 section 4.5.3.1 length limits

Not everything we want to validate will be in the ABNF grammar. Some things can't be expressed in ABNF. (For example, date-time rules like leap years.)

However, this section says: "Every implementation MUST be able to receive objects of at least these sizes. Objects larger than these sizes SHOULD be avoided when possible."

That sounds like it's valid for implementations to support parts larger than those limits. I think we should be testing that implementations work up to those limits. Beyond those limits, support is optional, so we shouldn't have tests for those.

2. Control and noncharacter codepoints in the local part (idn-email)

There's a link in the Errata that points to a discussion, but it's the wrong discussion. These are the relevant discusion.

• https://mailarchive.ietf.org/arch/msg/ima/G0SWdri-F9-nYYZ1EKpHQRKiE40/
• https://mailarchive.ietf.org/arch/msg/ima/PxbntvTSCFOvZuu0YOZTr-aZtBY/

Both replies assert that the ABNF is correct. The text in question was intended to be a clarification, not to add any constraints. Therefore, we can ignore the errata and only consider the ABNF, which is well defined.

atext           = UTF8-non-ascii
UTF8-non-ascii  = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2          = %xC2-DF UTF8-tail
UTF8-3          = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
                  %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
UTF8-4          = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
                  %xF4 %x80-8F 2( UTF8-tail )
UTF8-tail       = %x80-BF

[RishiByte]

@jdesrosiers Thanks for the clarification. That makes sense.

So, if I understand correctly:

• The grammar should remain the source of truth for syntax validation.
• The 64/255 length limits shouldn't be enforced as syntactic validation tests, since they're implementation/transport constraints.
• Likewise, characters allowed by the RFC 6531 ABNF should be accepted, even if some explanatory text or errata appears more restrictive.

In that case, I'm happy to update the tests accordingly so they validate the grammar rather than implementation-specific restrictions.