Web Key Directory (dealing with subaddressing?)

Bernhard Reiter bernhard at intevation.de
Wed Jun 1 09:52:16 CEST 2016

Am Mittwoch, 18. Mai 2016 17:53:28 schrieb Werner Koch:
> On Tue, 17 May 2016 15:07, bernhard at intevation.de said:
> >  148 The so mapped "local-part" is hashed using the SHA-1 algorithm.
> >
> > What about the common pattern of subaddressing?
> Still part of the local-part thus it does not matter.  It is an open
> question on how to handle such sub-addressing.  I discussed this in
> detail with Neal while thinking about TOFU; our conclusion was that it
> is to early to settle for a standard on how to canonicalize such
> addresses. If that makes sense at all.

The server must know, as it will do the email routing.
This is why me (and I believe  Guilhem, too) think that
transfering the original localpart to the server and let the
server do the decisions about an and if to handle this
maybe be a good idea to consider further.

> > I think there is merit in letting the server decide, how to treat it.
> That is the idea of the RFC but not the idea of the user.  Users don't
> care about case and use whatever case they got (e.g. from papers).  I
> have also seen people who are in the habit of always upcasing mail
> addresses.

Letting the server (of the mail service provider (MSP)) decide how to deal 
with the local-part is best for the user and she can continue to use all the 
interpretations that her MSP offers without further configuration.
The user does not care about if this is implemented in her client
or on her MSP's server.

Best Regards,

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...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160601/704fe53d/attachment.sig>

More information about the Gnupg-devel mailing list