avoid Alias pollution

[BasePointer]

So I've noticed that every time I get an E-Mail to a new alias, that alias gets created automatically (if catch all is enabled for a domain).

This means that over time the Alias table grows larger and larger. I imagine this could become a performance issue, especially if you have multiple domains.

Wouldnt it make much more sense if the alias and reverse alias were simply derived from one another on-the-fly? Maybe you would loose statistics and metadata connected to that Alias (forwards, blocks, replies, alias name, alias note) but I am not sure whether everyone needs that.

[IzumiSenaSora]

Same problem here!
I think we can have a new feature under every domain
"Catch-All Without creating new Alias"
If anyone turn it on! They can Catch-All email without creating new aliases! And it will be user choice! If they turn on this feature they will loose (logs, reply etc)...

[BasePointer]

I already figured that it probably doesnt affect performance alot. Anyway, one example on how to do it could be:

Reverse Alias = AES_Enc(some_key, alias_email+destination_email) + "@simplelogin.co"

[nguyenkims]

Currently we use a different way to generate reverse-alias. What is the benefit of using AES_Enc function here?

[BasePointer]

You wouldnt have to store the connection between the alias and reverse alias to a database. You can simply decrypt the part before the @ in the reverse alias and thereby restore the info on where to send the mail, no?

[nguyenkims]

Oh I see. Currently the reverse-alias is totally randomly generated (i.e. no link to the contact address or alias).

[BasePointer]

Something that just came to my mind is that the limit for usernames before the @ is 64 characters. Probably a dealbreaker for my suggestion.