Web Key Directory handling of IDN

[Peter Lebbing]

On 07/11/16 13:58, Jürgen Schäpker wrote:
> The current draft WKD will only be able to find non-ASCII address
> hashes by pure chance. MUAs can look for the hashes of
> Öyvind at something.net and öyvind at something.net and only for one WKD
> will return a result.

And what does the mail server do? It is not clear to me at all that the
mail server fares any better. Are you working here with a specific MTA
application in mind that happens to misuse IDN for normalizing local
parts? (IDN is for domain names, not other UTF-8 encoded data)

Do you happen to know how some major MTA's (Exim, Postfix, Sendmail,
Exchange[1]) handle this?

> "a" is not the normalized form of "ä". To get a clearer picture of an
> IDNA2003 conversion try http://www.dotarai.com/idna/
> 
> Jürgen and jürgen convert to xn--jrgen-kva

I don't see your point. So I register the e-mail address xn--jrgen-kva
instead of jurgen. It was just an example, the details are freely
exchangeable and my point stands.

> No. Not if you don't control the redirecting server.

Let's agree to disagree.

> you cannot rely on finding a single god admin for all domains that
> should be served by a single WKD.

I don't follow this single admin line of thought. I simply do not know
what you mean.

> If there is no valid technical reason for a requirement that will
> limit a standard's applicability, it should not be in the standard.

I agree. I just seem to disagree on the validity of the technical
reasons discussed.

Cheers,

Peter.

[1] Exchange can't even implement the most basic SMTP things correctly,
so I'm not so sure it should qualify for a look at it. Just the other
day I received some backscatter spam from an Exchange server. It was
doing a bounce report for a bounce report. The original bounce report
correctly had the null return route, but Exchange still thought it a
good idea to generate another bounce report for it, which it sent from a
non-null return route. In different circumstances, the mail could have
bounced around indefinitely. Throw in a non-fatal SMTP error somewhere
and it could have grown exponentially on the retries. I've heard of a
server going down under the load in this precise circumstance because
the Exchange server on the other end not even got this totally basic
null return route stuff right, which is very explicitly in the standard,
including the comment that it is precisely to prevent endless bouncing
around.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>