Frank Ellermann wrote:
Alessandro Vesely wrote:
the alphabet we use doesn't allow a third case beyond %{l}
and %{L}. Does that call for additional macro transformers?
I think %{L} is good enough for the purpose of URIs in an
explanation.
Yes, it is. Since there is a script that receives such parameter, it
can always work out whatever transformation it needs to do its job.
Unless folks try to put %{L} into a host name [...]
When spf-eai says "The local part MUST NOT be transformed"
it implies that %{l} cannot be used for DNS lookups if
internationalized local parts are present.
No, it implies "use the local part octets as is", because
that's also what happens outside of EAI in SPF.
Thus, if a site suitably restricts the local parts that users can
choose, then it will be able to use %{l} for actual DNS queries.
Otherwise local parts may not be used in, say, exist mechanisms -with
or without EAI. Therefore, it makes little sense to widen the set of
DNS-querable local parts by including U2A transformations. Is that
correct?
I wonder if, that being the case, the deeper analysis in your I-D
shouldn't be directed toward library implementors rather than policy
publishers.
I can log a query, but I won't know if it passed or failed.
Add the sending IP to your SPF exists: logging magic, then
you'd know what the result should be.
Hm... except for failures, policy restrictions, or possible
misinterpretations in the remote spf implementation.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com