On 15/04/2016 19:40, Mark Andrews wrote:
In message <571112B1(_dot_)7040206(_at_)pscs(_dot_)co(_dot_)uk>, Paul Smith
writes:
On 15/04/2016 16:22, Alexey Melnikov wrote:
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?
Isn't that just asking for trouble?
Either it'll be useless in real life, or it'll be the equivalent of the
existing VRFY command which everyone has enabled on their SMTP server
because it's never, ever, been misused </sarcasm>
verify != canonicalization. One checks existance the other doesn't.
If SMTP servers provided a canonicalization service
Case insensitive
CANON loCal(_at_)eXamPle(_dot_)CoM
200 local(_at_)example(_dot_)com
Google's remove dots + case insensitive would result in
CANON lo(_dot_)C(_dot_)al(_at_)eXamPle(_dot_)CoM
200 local(_at_)example(_dot_)com
But that makes the huge assumption than for a server, the rules are the
same for all users.
On a few servers they may be, for most the probably aren't. So, you
can't 'canonicalise' a name without checking the name.
It is entirely possible that one server could give these two responses
to your fictional command:
CANON fred(_dot_)smith(_at_)example(_dot_)com
200 fred(_dot_)s(_at_)example(_dot_)com
CANON fred(_dot_)brown(_at_)example(_dot_)com
200 f(_dot_)brown(_at_)example(_dot_)com
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp