On 07-01-14 07:32, Mark Andrews wrote:
All of which is irrelevent provided you can encode that into a policy
which can be transmitted.
It is not possible to handle these without substantially complicating
the logic. One would have to query the domain for the domain's
recipient delimiter first, and then for the address.
So. One of the reasons to go with base32 and not raw binary is
that the DNS does normalisation which is potentially different to
the normalisation done by the SMTP server.
At a minimum we should be able to specifying "no normalisation" vs
"case fold" (and which direction) for ascii LHS.
Seems to me these are both the same issue, and they could either be
resolved with one (probably nasty) policy-specification, or not at all
(leave 'em out like smtp does). Not a big fan of either :)
Yes, it makes things more complicated but the real world is
complicated.
Remember that one is comparing this to a SRV record which points
to a key server that does all the normalisation required to return
the correct key 100% of the time.
Are you suggesting this as a possible solution (which sounds more like
using DNS(SEC) to specify personal pgp key servers to get around the
current pgp key server problem)?
(while I type this, I wonder whether this functionality should be on
this level in the first place; shouldn't it fit better in smtp itself,
which is the only real place that currently know what normalization and
other rules apply?)
One small thing on the draft itself: IMO the last part of section 2
should not use 2119 terminology; it's not about interoperability nor
implementation. Oh and 'sent' should be 'send' :)
Jelte
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
