[GH-ISSUE #328] [Feature request] Set PGP key for recipient on account registration (and use it when sending verification email) #273

New issue

Closed

opened 2026-03-01 17:46:12 +03:00 by kerem · 0 comments

kerem commented

2026-03-01 17:46:12 +03:00

Owner

Originally created by @alexaka1 on GitHub (Aug 28, 2022).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/328

Scenario:

When registering a new account, the user is required to provide a recipient (and verify it) to complete registration and unlock the service (-failure to do so deletes the account in a month or so).
When clicking register, the verification email is sent immediately with no encryption (duh). But the user can access the site and change settings such as the initial recipient address. In recipients the user can provide a PGP public key, and enable encryption to an unverified email (this is actually the case for existing accounts as well), but from what I tested, email verification never uses the PGP key.

Request no.1:

Provide a field on the registration form, where a new user can optionally provide a PGP key, and use encryption from the very first interaction with the forwarding service. This could potentially be a UX issue for normie users, who'll be turned away by a scary checkbox called Advanced mode, that enables the PGP form input and other advanced features down the line.

Request no.2:

For a new recipient (be it completely new AnonAddy account or just a new recipient address) have an option to not send the verification email when just adding the address, so the user can upload a PGP key (at /recipients, and then click re-send verification button, and recieve E2E verification email to the new address.

Justification:

AnonAddy offers PGP support in the free tier (unless this is subject to change in the future) and recently you updated the codebase to use PGP for non-forwarding emails as well (notifications, payment confirmations etc.), so the ability to use E2E communication from the beginning makes sense. In my opinion the PGP support for AnonAddy is only for privacy against one's email provider, ie. gmail, so not letting the provider read the initial verification link, could potentially be a use-case for some users.

Originally created by @alexaka1 on GitHub (Aug 28, 2022). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/328 ### Scenario: When registering a new account, the user is required to provide a recipient (and verify it) to complete registration and unlock the service (-failure to do so deletes the account in a month or so). When clicking register, the verification email is sent immediately with no encryption (duh). But the user can access the site and change settings such as the initial recipient address. In recipients the user can provide a PGP public key, and enable encryption to an unverified email (this is actually the case for existing accounts as well), but from what I tested, email verification never uses the PGP key. ### Request no.1: Provide a field on the registration form, where a new user can optionally provide a PGP key, and use encryption from the very first interaction with the forwarding service. This could potentially be a UX issue for normie users, who'll be turned away by a scary checkbox called Advanced mode, that enables the PGP form input and other advanced features down the line. ### Request no.2: For a new recipient (be it completely new AnonAddy account or just a new recipient address) have an option to **not** send the verification email when just adding the address, so the user can upload a PGP key (at `/recipients`, and then click re-send verification button, and recieve E2E verification email to the new address. ### Justification: AnonAddy offers PGP support in the free tier (unless this is subject to change in the future) and recently you updated the codebase to use PGP for non-forwarding emails as well (notifications, payment confirmations etc.), so the ability to use E2E communication from the beginning makes sense. _In my opinion the PGP support for AnonAddy is only for privacy against one's email provider, ie. gmail, so not letting the provider read the initial verification link, could potentially be a use-case for some users._