[GH-ISSUE #421] [Enhancement] Disallow inclusion of plus address when creating alias. #877

Closed
opened 2026-03-14 10:59:54 +03:00 by kerem · 6 comments
Owner

Originally created by @RokeJulianLockhart on GitHub (Jan 20, 2023).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/421

I accidentally included a plus address in an alias that I created. This hasn't been a problem, since sending mail with a different plus address (obviously as replacement to the original rather than appended) and without any plus address deliver mail to the base address without problem.

However, I see no benefit to including it in the original address in the interface, whereas it certainly may cause confusion, as it did for me, since the mail delivery subsystem treats it as one would probably hope.

Summarily:

  1. Disallow creating mailTo:base-address+plus-address@anonaddy.com.

  2. Perhaps, correct to mailTo:base-address@anonaddy.com.

    1. However, do not modify current direction functionality.

I don't consider this to be important, but I certainly believe that it's worth implementing.

Originally created by @RokeJulianLockhart on GitHub (Jan 20, 2023). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/421 I accidentally included a plus address in an alias that I created. This hasn't been a problem, since sending mail with a different plus address (obviously as replacement to the original rather than appended) and without any plus address deliver mail to the base address without problem. However, I see no benefit to including it in the original address in the interface, whereas it certainly may cause confusion, as it did for me, since the mail delivery subsystem treats it as one would probably hope. Summarily: 1. [ ] Disallow creating `mailTo:base-address+plus-address@anonaddy.com`. 1. [ ] Perhaps, correct to `mailTo:base-address@anonaddy.com`. 1. [ ] However, do not modify current direction functionality. I don't consider this to be important, but I certainly believe that it's worth implementing.
kerem closed this issue 2026-03-14 10:59:59 +03:00
Author
Owner

@willbrowningme commented on GitHub (May 26, 2023):

The + extension of an alias is recorded in a separate database column when a standard alias is first created.

This is mainly so that you do not forget that you included one when first making the alias.

If you created a new alias first+ext@johndoe.anonaddy.com as your login for a site but then AnonAddy removed the +ext bit and didn't record it then you may later try to login with first@johndoe.anonaddy.com forgetting that you had used an extension.

<!-- gh-comment-id:1564054988 --> @willbrowningme commented on GitHub (May 26, 2023): The + extension of an alias is recorded in a separate database column when a standard alias is first created. This is mainly so that you do not forget that you included one when first making the alias. If you created a new alias `first+ext@johndoe.anonaddy.com` as your login for a site but then AnonAddy removed the `+ext` bit and didn't record it then you may later try to login with `first@johndoe.anonaddy.com` forgetting that you had used an extension.
Author
Owner

@RokeJulianLockhart commented on GitHub (May 26, 2023):

https://github.com/anonaddy/anonaddy/issues/421#issuecomment-1564054988

Yeah. @willbrowningme, I don't believe that we should retroactively remove them – just prevent creation of new ones with them (since, as you state, they're able to be overriden anyway, so they're not actually part of the address).

<!-- gh-comment-id:1564304489 --> @RokeJulianLockhart commented on GitHub (May 26, 2023): > https://github.com/anonaddy/anonaddy/issues/421#issuecomment-1564054988 Yeah. @willbrowningme, I don't believe that we should retroactively remove them – just prevent creation of new ones with them (since, as you state, they're able to be overriden anyway, so they're not actually part of the address).
Author
Owner

@willbrowningme commented on GitHub (May 26, 2023):

It is not overridden if you send a message to the same alias with a different plus extension. Only the one that was present when it was first created it stored.

If I prevent the creation of new ones with any extension then their will be no record of the full email used when creating a login etc.

<!-- gh-comment-id:1564331031 --> @willbrowningme commented on GitHub (May 26, 2023): It is not overridden if you send a message to the same alias with a different plus extension. Only the one that was present when it was first created it stored. If I prevent the creation of new ones with any extension then their will be no record of the full email used when creating a login etc.
Author
Owner

@RokeJulianLockhart commented on GitHub (May 26, 2023):

@willbrowningme,

It is not overridden if you send a message to the same alias with a different plus extension.

It is: If I create username+one@anonaddy.com but send a message to username+two@anonaddy.com, the message is not sent to username+one+two@anonaddy.com. It's sent to username+two@anonaddy.com. That's the entire crux of this issue – that that behaviour is deceptive.

If I prevent the creation of new ones with any extension then their will be no record of the full email used when creating a login etc.

How? Not if you prevent creation of them. All that the form has to do is either disallow entry of the sub-address, or reject the sub-address when the e-mail address is created.

<!-- gh-comment-id:1564363601 --> @RokeJulianLockhart commented on GitHub (May 26, 2023): @willbrowningme, > It is not overridden if you send a message to the same alias with a different plus extension. It *is*: If I create username+one@anonaddy.com but send a message to username+two@anonaddy.com, the message is *not* sent to username+one+two@anonaddy.com. It's sent to username+two@anonaddy.com. That's the entire crux of this issue – that *that* behaviour is deceptive. > If I prevent the creation of new ones with any extension then their will be no record of the full email used when creating a login etc. How? Not if you prevent *creation* of them. All that the form has to do is either disallow entry of the sub-address, or reject the sub-address when the e-mail address is created.
Author
Owner

@willbrowningme commented on GitHub (May 26, 2023):

With subaddressing (plus extensions) the underlying email address is the same. So in the eyes of AnonAddy username+one@anonaddy.com is the same alias as username+two@anonaddy.com.

It doesn't matter what extension you add, the message will still go to the same underlying alias username@anonaddy.com.

Appending multiple extensions and sending to username+one+two@anonaddy.com is not the expected behaviour.

You can inspect the headers of any forwarded message and view the X-AnonAddy-Original-To: to see if it was sent to the alias including a plus extension.

https://www.codetwo.com/admins-blog/plus-addressing/

Many users choose to use plus extensions for their aliases and if I disabled it then it would also break the feature described here https://anonaddy.com/blog/add-recipients-to-aliases-at-creation-and-new-uuid-aliases/.

<!-- gh-comment-id:1564442519 --> @willbrowningme commented on GitHub (May 26, 2023): With subaddressing (plus extensions) the underlying email address is the same. So in the eyes of AnonAddy `username+one@anonaddy.com` is the same alias as `username+two@anonaddy.com`. It doesn't matter what extension you add, the message will still go to the same underlying alias `username@anonaddy.com`. Appending multiple extensions and sending to `username+one+two@anonaddy.com` is not the expected behaviour. You can inspect the headers of any forwarded message and view the `X-AnonAddy-Original-To:` to see if it was sent to the alias including a plus extension. [https://www.codetwo.com/admins-blog/plus-addressing/](https://www.codetwo.com/admins-blog/plus-addressing/) Many users choose to use plus extensions for their aliases and if I disabled it then it would also break the feature described here [https://anonaddy.com/blog/add-recipients-to-aliases-at-creation-and-new-uuid-aliases/](https://anonaddy.com/blog/add-recipients-to-aliases-at-creation-and-new-uuid-aliases/).
Author
Owner

@RokeJulianLockhart commented on GitHub (May 26, 2023):

Many users choose to use plus extensions for their aliases and if I disabled it then it would also break the feature described here anonaddy.com/blog/add-recipients-to-aliases-at-creation-and-new-uuid-aliases.

Alright. I didn't know of that nifty feature. Thanks.

<!-- gh-comment-id:1564703510 --> @RokeJulianLockhart commented on GitHub (May 26, 2023): > Many users choose to use plus extensions for their aliases and if I disabled it then it would also break the feature described here [anonaddy.com/blog/add-recipients-to-aliases-at-creation-and-new-uuid-aliases](https://anonaddy.com/blog/add-recipients-to-aliases-at-creation-and-new-uuid-aliases/). Alright. I didn't know of that nifty feature. Thanks.
Sign in to join this conversation.
No labels
bug
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/anonaddy#877
No description provided.