Web Key Directory (dealing with subaddressing?)
bernhard at intevation.de
Wed Jun 1 10:06:32 CEST 2016
Am Mittwoch, 18. Mai 2016 19:15:43 schrieb Guilhem Moulin:
> Right, the recipient delimiter is a valid character in the RFC 5321
> local-part that is not allowed in account names. Clients shouldn't
> assume that messages sent ‘u+e at example.net’ are delivered to
> ‘u at example.net’. For instance ‘u+e’ and ‘u’ can very well be two
> different account names.
[citation moved further to the top:]
> Furthermore, letting the server interpret the *original* local part
> solves the case sensitivity issue I mentioned earlier.
I take it that you agree that it would be an advantage to let
the server see the original local-part and decide how to handle it.
The next question is
== How to transfer the original local-part?
> > We could just use the URL to transfer the full address or
> > /domain-part/local-part and then have the server decide.
> This conflicts with hashing the local part, since the server needs to
> reconstruct the original address from the given URL.
Yes, only using it in the url would be feasable exclusively in the case when
we do not hash.
> I agree with Werner that it not desirable to have non URL-safe characters
> in the local parts (such as ‘/’), but a base32-URL or base64-URL would do.
The goal is to ease implementations on the server and client sides, I assume.
As towards the danger of "non-url-safe" characters:
The server implementations will have to saveguard against malicious requests
anyway. If we define to interpret everything right off xyz/domain-part/
as being the local-part, I think there is no real danger and usual
URL percent coding of RFC3986 could be used, aka %2F for '/'.
== email alias names
> On a related note, should the server ensure that the same key is
> delivered for the account itself and its aliases? (Such as for
> login at example.org and full.name at example.org.) Since messages sent to
> either address are routed to the same account, it make sense to use the
> same key, but of course a downside is that it exposes the server's alias
> database. All in all I think the decision should be left to the user or
> service operator.
The question also occurred to me. I have not been giving it much thought
so far. One design idea could be that the client will add more user ids
(as a user often also needs to add more "identities" in the client to use
a specific from: address with real name and identify which emails are
www.intevation.de/~bernhard +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel