Execute rules on catch-all accounts
Currently filers and rules are not executed when using catch-all accounts. This feature is really important because especially when using catch-all additional filters would be really helpful to organize these mails.
I understand the request, but before we schedule this, I would like to better understand the actual use case.
@All: Could you please detail your catch all usage, with a practical example, and as well as give some examples as to what kind of rules you would create (e.g. 1. conditions, 2. actions)?
Thank you,
Gabriel
-
Matt Healey commented
Specific use case is being able to block specific incoming email addresses, while using a catch all. Once an email address starts to receive a lot of spam, we used to create a rule in Kerio that would simply mark anything to that address as spam and delete it. Creating a catchall, in Axigen seems to not run any rules, or give us the ability to deny-list a TO or CC address (only From), and makes having a catch-all very cumbersome.
So I agree with the other statements. Have a catch-all go to a specific account, and then let rules at the Server/Domain/Account level handle things from there.
-
Emy Cârlan commented
I think this is a Bug, rather than Feature Request. It's extremely frustrating when the filters don't work.
In our case, we have hello@ourdomain.com where we catch-all emails like contact@, office@, sales@ or test email accounts that we use when beta-testing our product: test1@, test2@ etc. We'd like to see these emails in the same Webmail session, but filtered in separate folders.
We tried adding some aliases, such as subscriptions@, team@ etc. but the filters still don't apply.
-
Brian Williams commented
I guess I should add that this isn't solely a spam issue. As the others have pointed out, there are other types of rules that one might want to apply in addition to spam related rules. The point is that any rules that are defined are being ignored. Email goes to whatever folder is defined in the catch-all account definition and that is that.
-
Brian Williams commented
I don't think you understand what I was trying to say or I didn't say it very well. When using a catch-all account, the behavior that I am seeing is that emails are always going to the Inbox regardless of any rules that may exist on the server regarding the X-AxigenSpam-Level. The spammiest email in the history of the internet is always going to land in the inbox. I believe this is because when you define the catch-all account, you are required to define both the account to which the email should be redirected AND the folder into which the email should be placed.
What I think should happen is that the email should be redirected to the desired account and then let whatever rules are defined determine if the email is spam and, if so, deal with it in the appropriate manner.
I hope that clarifies the issue.
-
Anonymous commented
The idea is:
You have a domain mydomain.tld - with catchall enabled.
So you can signup at ebay with ebay@mydomain.tld and amazon with amazon@mydomain.tld and some spamsite with spam@mydomain.tld
So now the idea would be to move all mails that came in with ebay@mydomain.tld to a folder named "ebay" and so on...
-
Anonymous commented
One simple example is:
We signup with ebay@domain.tld and amazon@domain.tld and netflix@domain.tld and want to move to mails with ebay to a folder ebay and amazon to a folder amazon, etc.
RULE:
if (receipient email is amazon@domainl.tld)
move to folder "amazon" -
Brian Williams commented
I agree with this. However, the issue isn't that the rules aren't being run on the emails. The issue is that no matter what the filters/rules determine, the mail always gets delivered to the inbox of the catch-all account. That, I think, is a flaw in how Axigen envisions catch-all accounts. When you configure the catch-all account, you are required to define the folder where the email will be delivered. That is the problem. Rather that just delivering email to the "account" and let the rules direct it to the appropriate folder, Axigen developers are requiring that the delivery folder be specified and that specification overrides all of the other rules. That is a mistake, in my humble opinion.