ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] New Mailing List to discuss email canonicalization?

2016-04-22 12:26:37
On Thu, Apr 21, 2016 at 11:33 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com> 
wrote:

Coming back to this after a week's thought...

--On Friday, April 15, 2016 16:22 +0100 Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:

Now, if someone claims that the language in 5321 is
insufficiently clear on that point, discussion of a proposed
update to clarify it might be useful.  However, I doubt that
is what proponents of "canonicalization" have in mind.  What I
think I'm seeing is claims that 5321 is either ambiguous or
says something else by people who don't consider reading and
understanding it to be a necessary requirement for developing
standards about email.

I think it is not about changing RFC 5321, but being able to
express things like "this domain uses ASCII case-insensitive
local-parts" or "a(_dot_)b(_at_)gmail(_dot_)com is the same as 
ab(_at_)gmail(_dot_)com".
These can be expressed in some ways in DNS, being validated
using an SMTP extension by a final delivery MTA or expressed
in S/MIME certificates. (These are just 3 examples of what
people were talking about recently, I express no opinion about
their suitability for the task.)

Does this clarify what kind of "canonicalization" I am talking
about?

It does.  Certainly there is no inherent objection to delivery
systems announcing the rules they intend to use in interpreting
addresses.  However, when one turns to the DNS for such things,
I hope than any discussions are informed by history and
operational reality.   Part of that history is that the WKS
record was a key feature of the original design of the DNS for
applications.  It turned out to be a miserable failure, so much
so that it was necessary to formally deprecate it in RFC 1123.
At least IMO, two things went wrong with WKS and the factors
that caused them are, if anything, worse today.   First, in
today's vocabulary of "permissionless innovation", WKS
essentially required sufficient cooperation between application
developers and DNS administrators to get permission from the
latter each time a new application was enabled.  Second, the
requirement created race conditions: if a function that had been
supported on on the applications server changed and it took the
DNS some time to catch up, assorted bad things happened.  How
bad depended on how much the client/sender trusted the DNS entry
and how it dealt with either the possibility of false positives
and negatives, but the best outcome was extra wasted time.

Similar issues, or at least the time-delay and race condition
ones may arise embedding addresses in certificates, but there
one may care less.  Or not.

If one is sufficiently careful about scope of applicability and
clear about the assumptions and consequent risks, I don't see a
problem with any of those approaches.  Conversely, as soon as
one starts talking about a general address canonicalizer, or
email addresses as reliable and permanent identifiers, I think
one gets onto a steeply-angled slippery slope.


Regarding the suitability of embedding email addresses in certificates,
would it be fair to say that domains willing to live with permanent email
identities and narrowly defined delivery patterns could have a standardized
means of describing equivalent email addresses?  Then recipients of emails
with such certificates could then validate the sender using a modified
RFC5280 validation.  Issuers of such certificates would have to insure that
the domain meets those requirements, and those that don't could be issued
certificates that fall back to current RFC5280 behavior.

-Wei


    john


best,
    john



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

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] Current Thread [Next in Thread>