Exactly which application should be processing the whitelist and blacklist spamfilter policies? I'm using Rspamd. If I use 'rspamc' to test a mail item, will it use the w/b data? I'm not sure exactly where in the postfix / dovecot pipeline that this data is used. Also, assume mail comes from [email protected]. Is it enough to use "example.com" in the sender spec? Is the @ required? That would require entries for each subdomain. Is this text processsed as a regex? There's no info about this stuff in the ISPConfig doc - only details about the form entries. Thanks!
I believe only rspamd. I don't really understand what you mean, but probably "no". rspamc is used to train the bayes db, it doesn't scan mail or otherwise make sense for it to use w/b data. I'm pretty sure it is not; it is added as eg. 'rcpt = "[email protected]";' in an rspamd settings file.
About rspamc, we can use the 'symbols' command (rather than learn_ or fuzzy...) and it will report the classification of the mail item. I didn't know if ISPConfig added this data into rules that are used by Rspamd. I was hoping someone could clarify with confidence that some specific symbol/rule makes use of this data, and then I would be sure to craft the data in a way that's acceptable for that purpose. As I said, not knowing if that data is used as a regex, or against which envelope field, it's tough to know what our options are. As long as I know: I'll look at where the data is saved and work out how it's used from there. I'll post findings here later. Thanks as always. (And BTW, it's good to see you in Rspamd circles too. )
Temporary documentation on ISPConfig Email > Spamfilter Whitelist and Blacklist This information applies in v3.2 when the lists are processed by Rspamd. Since the whitelist and blacklist functionality is the same, any reference here to 'whitelist' "should" apply to both types. However, per issue #6356 the blacklist is not working in v3.2. This note will be edited when issue #6082 has been processed. Fields: User, Email, Priority, Active Each whitelist entry results in a file created under /etc/rspamd/users/local.d/users. There is one 'rule' per file. Rspamd checks each rule file against inbound mail items. The filename is spamfilter_wblist_nnn.conf. nnn is a generated sequential integer, which is the key for the data in the ISPConfig database The User field in the UI is set in the rule as a 'rcpt' field. The Email field in the UI is set in the rule as a 'from' field. A spamfilter_wblist_99.conf file would then look like this: Code: spamfilter_wblist_99.conf { priority = 25; from = "text.from.Email.UI.field" rcpt = "text.from.User.UI.field" want_spam = yes; # for whitelist apply { actions { … accept all mail … } } } For information about that structure, see this Rspamd doc page. The priority field in the rule is not the same as the Priority in the UI. The rule value is the UI value + 20, so UI Priority 9 = 9 file value 29. Rules with higher priority take precedence over others. So, assume there are two rules, one for whitelist based on recipient (rcpt) address, and one for blacklist based on the sender (from) address. One email might match both rules. The rule with the highest priority number will be applied to the mail item. If a whitelist record has Active unchecked, the file is deleted from the config folder. When re-activated, the same filename is used using the ISPConfig key. In the example above, activating, deactivating, and reactivating the '99' record always results in the same .conf file being generated. In Rspamd, the from and rcpt fields are processed as regexp, not literal strings. ISPConfig offers a pre-defined dropdown list of User values, either @domain or user@domain, so regex cannot be used in the UI for this field. But the Email/from field is open for regex or exact matches. By default the Rspamd comparisons on the from/rcpt fields are Case-Sensitive. This can be changed with the 'i' flag (see example below). Regexp rules can be slow and should not be used extensively. Examples: Inbound address = [email protected] Matching Email values bad.domain < regex looks in field for this substring ^bad_.* < username starts with 'bad' @(.*\.)*domain < domain or any subdomain of domain /bad_actor/i < case-insensitive matches "Bad_Actor" EDIT 2022/07/25 : The .conf file might not be created with a regexp. https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/6367 ISPConfig Email > Global Filters > Postfix Whitelist and Blacklist Fields: Filter, Regexp Pattern, Data, Action. The Filter describes the part of the email item to which the filter is applied. Supported Filter types are Header, Body, MIME-Header, and Nested Header. The type specified determines the filename where the filter is written: Header > /etc/postfix/header_checks Body > /etc/postfix/body_checks MIME-Header > /etc/postfix/mime_header_checks Nested Header > /etc/postfix/nested_header_checks The Regexp Pattern is written as-is into the file. Surround complex patterns with delimiters, most commonly '/'. For example: Header filter : /^From: .*@bad_doman.tld/ The Action is added to the pattern in the file. Examples include REJECT, WARN, and DISCARD. The Data field is used by the Action. For example, for a REJECT, the Data value may contain a reason for the rejection. See Postfix docs for details about the files, actions, and more. ---- Would anyone like to confirm this? Thanks.
Hmm? I'm using ver. 3.2.8p1 and when I create a white and then a black both the same email, files are created as I grepped for them right after. Depending on each w/b priority, they allow and block as expected. I raise the whitelist and it comes through. The highest takes precedence. I delete the whitelist rule from inside the UI and the blacklist still blocks until removed as well. Your ISPC ver must be behind mine or I misunderstand that statement? Anyway, Nice Write-up!
Sincere thanks for checking. This is exactly the kind of response I like to see. Yeah, I'm running 3.2.2, but from the ticket I had the impression that nothing had changed in 3.2.x to make this version-specific, or even site-specific. If someone else with 3.2.2 reports the same issue, and someone else with 3.2.3+ reports success, then it seems we can assume this was a transient error. If someone else with 3.2.2 reports they can blacklist, then it seems something may be unique to my environment - and I'll start doing some diagnostics to see if I can nail what that is. Until then I'll just wait and blacklist manually in .conf files. Thanks again!
I would imagine that after they decide to release a Detailed .pdf maual over their regular ISPConfig 3.1 Manual they'll ask you or just add your educational material above.?.(I learned some from it). Thanks Back At Ya! p.s. Your tags cool, for I've been doing I.T. for 27 years myself, don't act like a know it all, can and Love Learning Something New Every Day!
Thanks again. Yeah, 58 now, started programming when I was 13, got my first offical paying tech job at 17. I'm am proud to have contributed a tiny bit to some documentation here. I confess that I did not keep up with that effort and probably disappointed those who were looking for more. I really appreciate this software and have learned a lot about it from usage and in this forum. I can only hope to allocate time to contribute something to this community. We take so much, and it's only fitting that we should give back whenever we have a chance. That's the way of FOSS. I'll make a commitment to ya - I'll add the above to the existing docs, report back here with links, and commit to adding more very soon. Thanks for the inspiration!
