In article <2611344.UcHi7X0hoO@kitterma-e6430> you write:
On Monday, January 22, 2018 07:44:13 PM John Levine wrote:
In article <FCA152FA-C67D-488E-AA7D-7234ED27EC19(_at_)kitterman(_dot_)com>
SPF can use mailfrom local parts, so that needs to be addressed in addition
to what's in the draft. I know it's not commonly used, but it is used and
is part of the standard.
Hmmn, I'm open to sugggestion but my inclination is to say that
anything with %s or %l macros fails with a non-ASCII local part. That
bit of SPF has always seemed rather ill-defined to me since it's never
been obvious what it means if a local part contains quotes or
parentheses or something like foo\.bar.
I don't have any opinion on the correct solution (I know almost nothing about
EAI and suspect it's good for my future sanity to try to preserve that state),
but one way or another, I think it needs to be addressed.
One nice thing about your proposed approach is that it's backwards compatible.
The other possibility is that they just expand macros using the UTF-8
and if that turns into hard-to-type DNS names, so be it. The DNS is
8-bit clean other than ASCII case folding, and since the DNS names
that these macros generate have never tried to be host names, random
8-bit UTF-8 crud is in principle no worse than underscores or plus
signs or spaces.
It is still my strong impression that these macros have always been
fragile since the interpretation of \. and the like is probably
whatever the host language's string and/or DNS libraries happen to do
ietf-smtp mailing list