[Feature Request] Conditional recipients

[ludwikc]

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

[email protected] -> [email protected]
[email protected] -> [email protected]

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.

[willbrowningme]

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".

[ludwikc]

Wunderbar!!!

On Mon 8. Mar 2021 at 15:19, Will Browning ***@***.***> 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 <#131 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACIUVB524P7QUWBXTB235K3TCTMF7ANCNFSM4YTXQWFA> .

-- -- Ludwik C. Siadlak Advanced Training Solutions email: [email protected] website: http://www.ludwikc.com

[galets]

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 [email protected]
...[1-9][1-9][02468].+   - send to [email protected]
.+                       - "all other" rule, goes to black hole, or to catch-all

this way emails sent to xyz419zzz, abc881, cde007 would automatically go to [email protected], emails sent to xyz410zzz, abc882, cde004 would automatically go to [email protected], and rest would be NDN, but the pattern would not be obvious.

[fazy]

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 [email protected] 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 [email protected] 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).

[galets]

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

[fazy]

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 [email protected] 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:

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.

[ludwikc]

So where are we on this one?

[willbrowningme]

I still need to add that "action" to the rules system to attach a recipient.

It is already possible though by using the recipient's "key" which can be found on the recipients page and then using that as the extension when creating new aliases e.g.

[email protected] -> [email protected]
[email protected] -> [email protected]

Where 1 and 2 are the "keys" of the corresponding recipients.

More details in this blog post - https://anonaddy.com/blog/add-recipients-to-aliases-at-creation-and-new-uuid-aliases/

[yurividal]

Any progress on this? It would be nice to be able to forward to different recipients depending on alias content.

[ludwikc]

yeah, an update would be wonderful Best regards / mit freundlichen Grüßen, Ludwik C. Siadlak

…

-------------------------------------------- *Ludwik C. Siadlak* * Advanced Training Solutions*

----------------------------------------- | Phone: +49 162 833 226 1 <+491628332261> | |-----------------------------------------| | Email: ***@***.*** ***@***.***>* | | Web: *www.ludwikc.co <http://www.ludwikc.co/>m* | |-----------------------------------------| | linkedin <http://www.linkedin.com/in/ludwikc> | twitter <http://www.twitter.com/ludwikc> | facebook <http://www.facebook.com/ludwikc> | blog <http://ludwikc.com/> | ----------------------------------------- [image: ➡] Sign up for a best, professional-level SQL course: [image: ➡] https://ludwikc.com/sqlbootcamp [image: ➡] …or learn basics of SQL in 60 mins! Sent via Superhuman iOS ***@***.***>

On Sat, Feb 11 2023 at 12:02 PM, Yuri Vidal ***@***.***> wrote: Any progress on this? It would be nice to be able to forward to different recipients depending on alias content. — Reply to this email directly, view it on GitHub <#361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACIUVB65ROHYLDB7GUAR7CDWW5WSVANCNFSM6AAAAAART5EVMI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[willbrowningme]

No update at the moment I'm afraid, hopefully in the next month or so I can get this added.

[yurividal]

HI @willbrowningme any progress on this feature. I know you have been busy with the rebranding of the project - and i appreciate that very much.
An update on whether this feature will ever get implemented would be cool