not sending confirmation email

Binarus lists at
Tue Sep 17 14:57:27 CEST 2019

At first, thank you very much for your explanations!

On 17.09.2019 12:17, Werner Koch wrote:
> On Tue, 17 Sep 2019 09:12, lists at said:
>> I am asking myself why Enigmail doesn't. I am not sure (and can't test
>> at the moment) how GnuPG would behave if given a problematic name when
>> generating a key; I hope it would give a warning or would add the
> gpg generates such a key just fine:
>   gpg --quick-gen-key "foo, bar | baz <foo at>"
> results in
>   pub   rsa3072 2019-09-17 [SC] [expires: 2021-09-16]
>       D5A13F45AD29FAD517FEB157F29010625F3EDDDA
>   uid                      foo, bar | baz <foo at>

I really hope that I don't annoy anybody (being in no way an experienced
user in this field and probably still missing many basics), but as far
as I have understood my communication with Vincent, it's such IDs which
are a problem for

When I first used Enigmail to generate and upload a key with such an ID
to, I never got the confirmation email.

When I uploaded that key using the web form
(, it told me that it couldn't parse the
key's ID as an email address.  Consequently, it couldn't send a
confirmation email, and the key, although having been stored on the
server, could not be found when being searched for by mail address.

> and gpg's internal mail-addr extraction function simply looks for the
> left angle bracket to find the mail-address and then checks whether that
> mail-addr is valid.

Thank you very much for that insight.

> The code also allows for a user-id consisting only
> of the mail-addr without the angle brackets.

This is the way I am going now. After the bad experience, I have decided
to use only key IDs consisting solely of the actual mail address
hereafter (with or without the angle brackets - I can live with both
variants :-)).

Enigmail refuses to generate such keys (it insists on entering a
non-empty name and doesn't complete the key generation process
otherwise). But I could easily generate such keys using the GnuPG
command line interface.

> The reason for this is
> that this de-facto standard only resembles an rfc-822 address but is not
> necessary valid.  For example due to the utf-8 encoding.

I see. Then the problem might be due to standards which are "only"
de-facto, leading to parsers (on the key servers) which interpret those
IDs subtly differently from what GnuPG / Enigmail and friends expect.

By the way, I did not test yet how would behave when
given a key ID with a comma in the name, but with the name quoted.

In every case, I am happy now, as long as IDs consisting only of the
actual mail address remain allowed. Personally, I currently don't need
to have my name or other fancy text in my keys' IDs. I suppose that
somebody who wants to write me an encrypted message will search for my
public key at first by email address (and not by other criteria). At
least, I would do so ...

Regards, and thanks again,


More information about the Gnupg-users mailing list