ietf-smtp
[Top] [All Lists]

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

2020-06-21 12:43:49
In article 
<kzlyExy/3YBZVUSNURxDqMLjYwWYAVGpn6yogCjhITg=.sha-256@antelope.email> 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 bob(_at_)example(_dot_)com and 
bob(_at_)EXAMPLE(_dot_)COM
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

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp