[GH-ISSUE #131] [Feature Request] Conditional recipients

kerem commented

2026-03-01 17:45:15 +03:00

Owner

Originally created by @ludwikc on GitHub (Mar 4, 2021).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/131

In paid plans with multiple recipients, it'd be great if one could set up conditioning. Meaning:

allrandomaliaseswith.sufix1@anonaddycustomdomain.com -> recipient1@mydomain.com
allrandomaliaseswith.sufix2@anonaddycustomdomain.com -> recipient2@mydomain.com

I understand it can be achieved using usernames or additional custom domains, but it generates additional configuration overhead. The above (I believe) simplifies the process.

Originally created by @ludwikc on GitHub (Mar 4, 2021). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/131 In paid plans with multiple recipients, it'd be great if one could set up conditioning. Meaning: allrandomaliaseswith.sufix1@anonaddycustomdomain.com -> recipient1@mydomain.com allrandomaliaseswith.sufix2@anonaddycustomdomain.com -> recipient2@mydomain.com I understand it can be achieved using usernames or additional custom domains, but it generates additional configuration overhead. The above (I believe) simplifies the process.

kerem closed this issue

2026-03-01 17:45:16 +03:00

kerem commented

2026-03-01 17:45:16 +03:00

Author

Owner

@willbrowningme commented on GitHub (Mar 8, 2021):

I will likely tie this in with the full release of the rules system, so you'll be able to set a condition say:

WHEN alias ends with "xyz".

THEN attach and send to recipient "abc".

@willbrowningme commented on GitHub (Mar 8, 2021): I will likely tie this in with the full release of the rules system, so you'll be able to set a condition say: WHEN alias ends with "xyz". THEN attach and send to recipient "abc".

kerem commented

2026-03-01 17:45:16 +03:00

Author

Owner

@ludwikc commented on GitHub (Mar 8, 2021):

Wunderbar!!!

On Mon 8. Mar 2021 at 15:19, Will Browning notifications@github.com wrote:

I will likely tie this in with the full release of the rules system, so
you'll be able to set a condition say:

WHEN alias ends with "xyz".

THEN attach and send to recipient "abc".

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/anonaddy/anonaddy/issues/131#issuecomment-792785759,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACIUVB524P7QUWBXTB235K3TCTMF7ANCNFSM4YTXQWFA
.

--
-- Ludwik C. Siadlak Advanced Training Solutions email:
ludwikc@siadlak.email website: http://www.ludwikc.com

@ludwikc commented on GitHub (Mar 8, 2021): Wunderbar!!! On Mon 8. Mar 2021 at 15:19, Will Browning <notifications@github.com> wrote: > I will likely tie this in with the full release of the rules system, so > you'll be able to set a condition say: > > WHEN alias ends with "xyz". > > THEN attach and send to recipient "abc". > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/anonaddy/anonaddy/issues/131#issuecomment-792785759>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACIUVB524P7QUWBXTB235K3TCTMF7ANCNFSM4YTXQWFA> > . > -- -- Ludwik C. Siadlak Advanced Training Solutions email: ludwikc@siadlak.email website: http://www.ludwikc.com

kerem commented

2026-03-01 17:45:16 +03:00

Author

Owner

@galets commented on GitHub (Jul 12, 2021):

Suffix is quite a clunky and obvious. I already see spammers realizing that *@mydomain emails are passed to my mailbox verbatim, and they already started spamming to random@mydomain.

May I suggest even a better way to address this feature request? Use a regular expression for aliases not in the database. This way you don't need to be obvious like it is with suffix. You can then set up rules such as:

known alias              - send to configured mailbox
...[1-9][1-9][13579].+   - send to myemail1@xx.com
...[1-9][1-9][02468].+   - send to otheremail2@xx.com
.+                       - "all other" rule, goes to black hole, or to catch-all

this way emails sent to xyz419zzz, abc881, cde007 would automatically go to myemail1@xx.com, emails sent to xyz410zzz, abc882, cde004 would automatically go to otheremail2@xx.com, and rest would be NDN, but the pattern would not be obvious.

@galets commented on GitHub (Jul 12, 2021): Suffix is quite a clunky and obvious. I already see spammers realizing that *@mydomain emails are passed to my mailbox verbatim, and they already started spamming to random@mydomain. May I suggest even a better way to address this feature request? Use a regular expression for aliases not in the database. This way you don't need to be obvious like it is with suffix. You can then set up rules such as: ``` known alias - send to configured mailbox ...[1-9][1-9][13579].+ - send to myemail1@xx.com ...[1-9][1-9][02468].+ - send to otheremail2@xx.com .+ - "all other" rule, goes to black hole, or to catch-all ``` this way emails sent to xyz419zzz, abc881, cde007 would automatically go to myemail1@xx.com, emails sent to xyz410zzz, abc882, cde004 would automatically go to otheremail2@xx.com, and rest would be NDN, but the pattern would not be obvious.

kerem commented

2026-03-01 17:45:16 +03:00

Author

Owner

@fazy commented on GitHub (Aug 16, 2021):

Completely agree with what @galets says. After a while, a domain will eventually find itself in the hands of spammers who don't mind trying every possible username before the @.

Even for someone who doesn't need to forward to different recipients, I do need to be able to say "forward emails when the To line starts with foo but reject everything else".

To be honest a simple prefix match would suffice for me.

Use cases:

I have an old domain using name-company@example.com where "name" is constant and "company" varies by company. I want to reject anything that doesn't start with name-.

Lately I use something like constant.company.random@example.com where "constant" is something "random" (generated like this), company varies by company I signed up to and random is some random (varying each time) digits. In this case I want to reject email to anything that doesn't start with constant..

Obviously RegEx is more powerful but will result in lots of support requests I expect. ;) Prefix is simple or a choice of prefix/substring/suffix.

I'm currently evaluating Anonaddy (and it's awesome!) but I would need this feature to handle my existing domains. I'm more than happy to pay for this feature (already paying Lite for evaluation).

@fazy commented on GitHub (Aug 16, 2021): Completely agree with what @galets says. After a while, a domain will eventually find itself in the hands of spammers who don't mind trying every possible username before the `@`. Even for someone who doesn't need to forward to different recipients, I do need to be able to say "forward emails when the To line starts with `foo` but reject everything else". To be honest a simple prefix match would suffice for me. Use cases: I have an old domain using `name-company@example.com` where "name" is constant and "company" varies by company. I want to reject anything that doesn't start with `name-`. Lately I use something like `constant.company.random@example.com` where "constant" is something "random" ([generated like this](https://xkcd.com/221/)), company varies by company I signed up to and random is some random (varying each time) digits. In this case I want to reject email to anything that doesn't start with `constant.`. Obviously RegEx is more powerful but will result in lots of support requests I expect. ;) Prefix is simple or a choice of prefix/substring/suffix. I'm currently evaluating Anonaddy (and it's awesome!) but I would need this feature to handle my existing domains. I'm more than happy to pay for this feature (already paying Lite for evaluation).

kerem commented

2026-03-01 17:45:17 +03:00

Author

Owner

@galets commented on GitHub (Aug 16, 2021):

The issue with plain prefix is that spammers have a way to generate unlimited emails, all of which are going into your mailbox, and you can't stop them. A simple script could do it:

take email_address
extract mx_domain (part after @) and user_name (part before @)
servers=nslookup -q=mx $mx_domain
do servers belong to anonaddy (e.g.: grep "anonaddy.me")?
if yes, then $user_name$RANDOM@$mx_domain will be valid email address to send spam to

You need more complex rules to protect from this attack.

Regex is not an ideal solution either though. A small regex could be crafted in a way that it would overwhelm the system as it's checking whether email is a match, which could be used to DDoS anonaddy's servers. This feature should probably be reserved to paying customers only

@galets commented on GitHub (Aug 16, 2021): The issue with plain prefix is that spammers have a way to generate unlimited emails, all of which are going into your mailbox, and you can't stop them. A simple script could do it: - take email_address - extract mx_domain (part after @) and user_name (part before @) - servers=`nslookup -q=mx $mx_domain` - do servers belong to anonaddy (e.g.: `grep "anonaddy.me"`)? - if yes, then $user_name$RANDOM@$mx_domain will be valid email address to send spam to You need more complex rules to protect from this attack. Regex is not an ideal solution either though. A small regex could be crafted in a way that it would overwhelm the system as it's checking whether email is a match, which could be used to DDoS anonaddy's servers. This feature should probably be reserved to paying customers only

kerem commented

2026-03-01 17:45:17 +03:00

Author

Owner

@fazy commented on GitHub (Aug 17, 2021):

You need more complex rules to protect from this attack.

I don't need to protect from this attack (at least, not completely).

For a 20-year old domain, I want to stop getting asdbfdfd@example.com and so on, while I gradually shut down or migrate old accounts linked to its email addresses. I can never prevent a targeted attack on this domain but until that happens the most convenient option is to filter out the attack that is actually happening.

For new domains, I would prefer to have the convenience of a catch-all until nefarious spammers get hold of it, while still avoiding the most obvious problem. I'm more careful with giving out email addresses than I was 20 years ago and privacy laws are stricter, so the time between me using a new domain and spammers guessing <anything>@domain is likely to be longer. When they do, they'd also have to guess the prefix (which no longer relates to my name) - and issuing a new prefix would be cheaper/easier than registering a new domain.

Bearing in mind that the catch-all rule is about auto-creating aliases, so let's suppose I take this approach with a new domain, and a year later the prefix is compromised:

oldprefix-<anything>@example.com - prefix compromised, only allow pre-existing aliases (and disable any specific alias that's compromised), don't auto-create new aliases
newprefix-<anything>@example.com - allow auto-creation of aliases (wildcard).

This is better than registering a new domain each time because once you've used a domain to sign up for anything linked to your personal data, it's not safe to let the domain registration lapse. Somebody else could register the domain and scoop up your email, gain access to any accounts etc.

Bearing in mind also that a big problem these days is supposedly legitimate companies that don't fully comply with GDPR and PECR. For example, the UK retailer John Lewis signed me up to their mailing list after using guest checkout. I complained to the ICO (UK regulatory body), the ICO ruled in my favour and John Lewis changed their website. But this is incredibly tedious and time consuming, multiplied by the huge number of companies that send me spam in the guise of lawful processing. Not everyone wants to take them all on in court. Anyway these emails are especially annoying because (a) it's almost impossible to avoid (especially since the pandemic with even more business happening online) and (b) they don't usually get sent to the spam folder.

So I have three problems:

Spammers guessing <anything>@example.com and filling my spam folder
Spammers guessing <prefix>-<anything>@example.com and filling my spam folder
Supposedly legitimate emails that are not compliant, or fall into the grey area of GDPR Article 6(1)(f), and filling my inbox

There are two approaches:

No catch-all, pre-assign random addresses. Not convenient but deals with all three.
Catch-all with filter. Deals with the first and third problems; doesn't solve the second problem, but mitigates it (no need for a new domain)

Which approach each person takes depends on their attitude to security vs. convenience. Bearing in mind that someone using approach 2 can switch to approach 1 later if the spam gets bad, I don't think there's much to lose. So I think some kind of filtering functionality will add value.

@fazy commented on GitHub (Aug 17, 2021): > You need more complex rules to protect from this attack. I don't need to protect from this attack (at least, not completely). For a 20-year old domain, I want to stop getting `asdbfdfd@example.com` and so on, while I gradually shut down or migrate old accounts linked to its email addresses. I can never prevent a targeted attack on this domain but until that happens the most convenient option is to filter out the attack that is actually happening. For new domains, I would prefer to have the convenience of a catch-all until nefarious spammers get hold of it, while still avoiding the most obvious problem. I'm more careful with giving out email addresses than I was 20 years ago and privacy laws are stricter, so the time between me using a new domain and spammers guessing `<anything>@domain` is likely to be longer. When they do, they'd also have to guess the prefix (which no longer relates to my name) - and issuing a new prefix would be cheaper/easier than registering a new domain. Bearing in mind that the catch-all rule is about auto-creating aliases, so let's suppose I take this approach with a new domain, and a year later the prefix is compromised: * `oldprefix-<anything>@example.com` - prefix compromised, only allow pre-existing aliases (and disable any specific alias that's compromised), don't auto-create new aliases * `newprefix-<anything>@example.com` - allow auto-creation of aliases (wildcard). This is better than registering a new domain each time because once you've used a domain to sign up for anything linked to your personal data, it's not safe to let the domain registration lapse. Somebody else could register the domain and scoop up your email, gain access to any accounts etc. Bearing in mind also that a big problem these days is supposedly legitimate companies that don't fully comply with GDPR and PECR. For example, the UK retailer John Lewis signed me up to their mailing list after using guest checkout. I complained to the ICO (UK regulatory body), the ICO ruled in my favour and John Lewis changed their website. But this is incredibly tedious and time consuming, multiplied by the huge number of companies that send me spam in the guise of lawful processing. Not everyone wants to [take them all on in court](https://www.mindmydata.co.uk/the-service-message-scam/). Anyway these emails are especially annoying because (a) it's almost impossible to avoid (especially since the pandemic with even more business happening online) and (b) **they don't usually get sent to the spam folder**. So I have three problems: 1. Spammers guessing `<anything>@example.com` and filling my spam folder 2. Spammers guessing `<prefix>-<anything>@example.com` and filling my spam folder 3. Supposedly legitimate emails that are not compliant, or fall into the grey area of GDPR Article 6(1)(f), and filling my inbox There are two approaches: 1. No catch-all, pre-assign random addresses. Not convenient but deals with all three. 2. Catch-all with filter. Deals with the first and third problems; doesn't solve the second problem, but mitigates it (no need for a new domain) Which approach each person takes depends on their attitude to security vs. convenience. Bearing in mind that someone using approach 2 can switch to approach 1 later if the spam gets bad, I don't think there's much to lose. So I think some kind of filtering functionality will add value.

Rows
Columns

[GH-ISSUE #131] [Feature Request] Conditional recipients #148