Re: [ietf-smtp] How wrong is this EAI implementation

[Ned Freed <[e-mail]>]

> In article <kzlyExy/3YBZVUSNURxDqMLjYwWYAVGpn6yogCjhITg=[e-mail]> you write:

> > I note that there is no explicit requirement to treat incoming a-labels
> > as equivalent with u-labels anywhere in the EAI RFCs. Which means that
> > you can convert labels before sending, but you cannot rely on the
> > receiver to interpret the result as desired.

The EAI documents repeatedly refer to there being two different "forms" for
domains, u-label and a-label. The only reasonable interpreration of such
statements is that the they are equivalent. RFC 6531 even goes so far as to
say that u-labels form should be used when the SMTPUTF8 extension is available,
a-label form when it isn't.

Additionally, the point that always seems to be elided in these discussions is
that MTAs do NOT have the luxury of treating addresses as opaque strings.
Elimination of duplicate addresses, alias lookup, and canonicalization  of
local address forms are all things that MTAs do routinely, and all of them
require at a minimum the ability to compare addresses and get correct results.
This combined with the "mutiple forms" notion in the documents leaves very
little wiggle room for implementers, explicit requirements or not.

And yes, it's a bit of a PITA to code.

> I don't think that 5321 requires that [e-mail] and [e-mail]
> be treated the same, either.

Section 2.4 explicitly says domains are case-insensitive. Not a lot of wiggle
room here either.

> Beyond some point, you can't force people to be reasonable.

No, but I think you can make a case that any implementation that fails to treat
the forms as equialent is incompliant.

> In the particular case I mentioned, my MTA is Courier which treats
> A-labels and U-labels equivalently in mail addresses, but not in
> identifiers for authentication.  It was easy enough to add both versions
> to the identifer table, but I think I'm going to send a bug report to
> roundcube.

Yet another case where comparisons are unavoidable.

				Ned