starred/anonaddy

Fork 0

mirror of https://github.com/anonaddy/anonaddy.git synced 2026-04-24 21:55:52 +03:00

[GH-ISSUE #782] [Feature Request] Temporary / Burner Email Aliases #1103

New issue

Open

opened 2026-03-14 11:44:28 +03:00 by kerem · 3 comments

kerem commented

2026-03-14 11:44:28 +03:00

Owner

Originally created by @nicolas-g on GitHub (Oct 22, 2025).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/782

Description:

It would be great to have the ability to create temporary or burner email aliases that automatically expire after a set condition is met. This would simplify the process of using short-lived email addresses without having to manually delete or clean them up later.

Proposed Functionality

Time-based expiration:

Allow the user to create a temporary alias that automatically self-destructs after a specified amount of time (e.g., 1 hour, 1 day, 1 week).

Usage-based expiration:

Allow the alias to self-destruct automatically after receiving a specified number of emails (e.g., after 1, 3, or 5 messages).

Benefits

Simplifies management of short-lived aliases
Reduces manual cleanup and clutter
Enhances privacy and security by limiting exposure time
Ideal for one-time sign-ups, testing, or untrusted services

Example Use Cases

Signing up for a service just once
Testing email workflows or app notifications
Avoiding spam after short-term registrations

Additional Suggestions

Option to manually extend the life of a temporary alias
Notification before alias deletion
Ability to set custom rules for expiration (time + message count combined)

Originally created by @nicolas-g on GitHub (Oct 22, 2025). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/782 ## Description: It would be great to have the ability to create temporary or burner email aliases that automatically expire after a set condition is met. This would simplify the process of using short-lived email addresses without having to manually delete or clean them up later. ## Proposed Functionality 1. Time-based expiration: > Allow the user to create a temporary alias that automatically self-destructs after a specified amount of time (e.g., 1 hour, 1 day, 1 week). 2. Usage-based expiration: > Allow the alias to self-destruct automatically after receiving a specified number of emails (e.g., after 1, 3, or 5 messages). ## Benefits - Simplifies management of short-lived aliases - Reduces manual cleanup and clutter - Enhances privacy and security by limiting exposure time - Ideal for one-time sign-ups, testing, or untrusted services ## Example Use Cases - Signing up for a service just once - Testing email workflows or app notifications - Avoiding spam after short-term registrations ## Additional Suggestions - Option to manually extend the life of a temporary alias - Notification before alias deletion - Ability to set custom rules for expiration (time + message count combined)

kerem commented

2026-03-14 11:44:34 +03:00

Author

Owner

@PACHAKUTlQ commented on GitHub (Nov 5, 2025):

nice, but how to prevent abuse? this surely makes abuse (creating lots of temp mail addresses to register online services) a lot easier, so this feature is at the cost of reputation of shared domain (if public one)/your own domain (if self hosted, but obviously you can do whatever you want if you self host)

@PACHAKUTlQ commented on GitHub (Nov 5, 2025): nice, but how to prevent abuse? this surely makes abuse (creating lots of temp mail addresses to register online services) a lot easier, so this feature is at the cost of reputation of shared domain (if public one)/your own domain (if self hosted, but obviously you can do whatever you want if you self host)

kerem commented

2026-03-14 11:44:39 +03:00

Author

Owner

@nicolas-g commented on GitHub (Nov 5, 2025):

nice, but how to prevent abuse? this surely makes abuse (creating lots of temp mail addresses to register online services) a lot easier, so this feature is at the cost of reputation of shared domain (if public one)/your own domain (if self hosted, but obviously you can do whatever you want if you self host)

Currently, there’s nothing preventing potential abuse of the service with the existing features. However, you could implement limits on the number of temporary emails a user can create per day or month, with different tiers based on their subscription plan. Additionally, you could restrict temporary email addresses only to a specific shared domain, similar to how most temporary email services operate.

@nicolas-g commented on GitHub (Nov 5, 2025): > nice, but how to prevent abuse? this surely makes abuse (creating lots of temp mail addresses to register online services) a lot easier, so this feature is at the cost of reputation of shared domain (if public one)/your own domain (if self hosted, but obviously you can do whatever you want if you self host) Currently, there’s nothing preventing potential abuse of the service with the existing features. However, you could implement limits on the number of temporary emails a user can create per day or month, with different tiers based on their subscription plan. Additionally, you could restrict temporary email addresses only to a specific shared domain, similar to how most temporary email services operate.

kerem commented

2026-03-14 11:44:44 +03:00

Author

Owner

@hampoelz commented on GitHub (Mar 3, 2026):

I'd love to see this feature! I often create aliases for reservations - in these cases, I usually only receive a confirmation mail and never need the alias again. It would be really handy to be able to create a temporary alias that automatically deletes itself after 24 hours.

@hampoelz commented on GitHub (Mar 3, 2026): I'd love to see this feature! I often create aliases for reservations - in these cases, I usually only receive a confirmation mail and never need the alias again. It would be really handy to be able to create a temporary alias that automatically deletes itself after 24 hours.

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#1103

No description provided.

Rows
Columns