--On Sunday, 06 October, 2019 20:48 -0400 Keith Moore
On 10/6/19 8:40 PM, John C Klensin wrote:
--On Sunday, 06 October, 2019 10:34 -0400 Keith Moore
Well, at least for this specific proposal, the only place
that it matters whether the name is an IDN is whether the
leftmost facet of the name is not ASCII and therefore
requires encoding. It won't confuse SMTP clients if
other facets of the name are non-ASCII.
Keith, I'm not sure what you are trying to say.
I'm specifically referring to giri(_at_)dombox(_dot_)org's proposal to
signal a MX's willingness to do TLS by putting a prefix
(smtps- or starttls-) on the target of an MX record. One
minor complication crops up if the first facet of an IDN
requires ASCII encoding. So an SMTP client can't merely look
for those prefixes in the MX record target, it has to look for
the encoded form of those prefixes also. A possible fix to
make the implementation simpler would be to prepend smtps. or
starttls. (or some other magic token) thus causing that
facet of the IDN to not require encoding.
Ah, ok. Makes sense. Probably even better to try to treat this
as a service, e.g., make the leftmost label "_smtps" or even
"_dombox" or the like. I haven't thought deeply about it, but
that model, which is reasonably well-defined, should work as
long as _dombox.mail.example.com. is treated as the name of a
host because, in the DNS record were, e.g.,
mysystem.example.com. MX 0 _dombox.mail.example.com.
it has to be an alias for something else or if it has to be
parsed in a special way, that would probably violate the SMTP
rule about MX targets.
ietf-smtp mailing list