What
The feature request has 2 parts.
- Improve documentation about the logic of how your filters work in your FAQs and/or in the domain settings for "Allowlisted Senders".
- A master (allowlist, denylist, greylist) filter bypass toggle on the domain settings for "Allowlisted Senders" (if true, no filters).
For the documentation, my specific questions are below.
If domains are added to the domain settings for "Allowlisted Senders", are the allowlist and/or denylist criteria in your FAQs still active?
Do the lists have priorities? If so, what are they? As an example, what happens if I specify the same domain in both the domain settings allowlist and domain settings denylist?
Is the general logic similar to the following?
if(allowlist.contains(fingerprint) and not denylist.contains(fingerprint))
{allow()}
else {deny();timing_counts.update(fingerprint)}
I took a quick look at the code but couldn't find where this is implemented.
Are wildcard TLDs (e.g. *.*.* vs. *.*.com) allowed in the domain settings "Allowlisted Senders"?
This would be an easy workaround and practically implement item 2.
If filtering is IP based, this may be more difficult to implement. I think permanent (no bypass) rules for rate limiting would be a good compromise.
See also Issue 332 and Issue 443.
Why
For me, one of the most important features of paid e-mail services is fine control over spam filters and filter e-mail retention.
Network issues aside, I would like to guarantee that I never miss an important e-mail even if it requires manual spam review and custom denylist development.
See also Issue 266.
Per user filters would be more similar to Gmail, iCloud mail, and Outlook.
While I have Spam Scanner fully disabled, I still see bounced e-mails and I suspect this is due to your allowlist rules.
The UPL requirements for your allowlist are also too strict for my and possibly other user's preferences.
I believe they would cause domains not on the UPL (small business, personal, academic, etc.) to be incorrectly greylisted or denylisted.
I have also had TTI issues with senders who are major corporations.
Reviewing spam received by aliases is also very useful for finding data leaks and security audits.
Complete filter bypassing is also practical for self-hosted relay servers with custom spam filters as well as client based filters.
Checklist
What
The feature request has 2 parts.
For the documentation, my specific questions are below.
If domains are added to the domain settings for "Allowlisted Senders", are the allowlist and/or denylist criteria in your FAQs still active?
Do the lists have priorities? If so, what are they? As an example, what happens if I specify the same domain in both the domain settings allowlist and domain settings denylist?
Is the general logic similar to the following?
I took a quick look at the code but couldn't find where this is implemented.
Are wildcard TLDs (e.g.
*.*.*vs.*.*.com) allowed in the domain settings "Allowlisted Senders"?This would be an easy workaround and practically implement item 2.
If filtering is IP based, this may be more difficult to implement. I think permanent (no bypass) rules for rate limiting would be a good compromise.
See also Issue 332 and Issue 443.
Why
For me, one of the most important features of paid e-mail services is fine control over spam filters and filter e-mail retention.
Network issues aside, I would like to guarantee that I never miss an important e-mail even if it requires manual spam review and custom denylist development.
See also Issue 266.
Per user filters would be more similar to Gmail, iCloud mail, and Outlook.
While I have Spam Scanner fully disabled, I still see bounced e-mails and I suspect this is due to your allowlist rules.
The UPL requirements for your allowlist are also too strict for my and possibly other user's preferences.
I believe they would cause domains not on the UPL (small business, personal, academic, etc.) to be incorrectly greylisted or denylisted.
I have also had TTI issues with senders who are major corporations.
Reviewing spam received by aliases is also very useful for finding data leaks and security audits.
Complete filter bypassing is also practical for self-hosted relay servers with custom spam filters as well as client based filters.
Checklist