In article <155486669171.19715.14014281020759221500.idtrac...@ietfa.amsl.com>
you write:
>I agree with Benjamin's DISCUSS comment: this document needs to better
>explain the consequences of the inability to match %{s} and %{l}.
It has no consequences at all. As Scott noted, it documents what the code does
now.
He talks about
>it from a security perspective, but I think there's also a discussion to be had
>here about whether this disadvantages users who elect to have non-ASCII
>characters in their mailbox names.
I have to object here -- this is asking us to put a tutorial about SPF
into this minor update document. Anyone who is familiar with SPF
knows that local part macros are useless and it makes no difference.
Even if they weren't useless and we we wanted to encode UTF-8 local
parts in the DNS, that doesn't work because the semantics of local
parts and of domain names and the way they are interpreted are very
different. The obvious problem is case folding which has in the past
kind of mostly worked because the ASCII DNS case folding rule and
ASCII mail case folding conventions happen to be similar, but it goes
straight downhill from there with characters other than ASCII letters
and digits. This has been argued to death many times, and again this
is not the place for a tutorial.
R's,
John
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
