D
@marcusquinn said in Sharing custom SpamAssassin Rules:
Nice, so which would you recommend?
For the Cloudron DNSBL list? I personally am using Spamhaus and Abusix's Exploit list to completely reject only the most obvious of spam, leaving the rest to be filtered via SpamAssassin to the inbox or junk folder.
zen.spamhaus.org
{API_KEY}.exploit.mail.abusix.zone
I stumbled across this page this evening: https://docs.umami.is/docs/enable-redis
It seems like Umami can take advantage of Redis for some performance improvements. Just wondering if maybe this should or could be added to the Umami package in Cloudron.
@imc67 said in Sharing custom SpamAssassin Rules:
@msbt said in Sharing custom SpamAssassin Rules:
Thanks a bunch for the list @d19dotca! Quick question about the rest of the setup though: Do you still have entries in the Email ACL DNSBL Zones or is that empty because everything is handled in the custom rules? Like those:
zen.spamhaus.org bl.mailspike.net noptr.spamrats.com dnsbl.sorbs.netOr is that empty on your side?
I think this is still a relevant question, @d19dotca your spam-rules are amazing, however you are "calling" ACL DSNBL's that are not default in a Cloudron install (https://docs.cloudron.io/email/#dnsbl) so I guess that they are not working until you add them?
I asked ChatGPT to analyse your latest rules and it advised to add the below ones to the DNSLBL Zones ACL (https://my.domain.com/#/email-settings). Is that in your opinion correct to make them all work?
zen.spamhaus.org bl.mailspike.net noptr.spamrats.com all.spamrats.com backscatter.spameatingmonkey.net bl.spameatingmonkey.net netbl.spameatingmonkey.net
So just to clarify… if you add those to the DNSBL list in Cloudron mail settings, it will completely reject mail that has a hit on any of those services. That mail setting in Cloudron is used by Dovecot/Haraka, not SpamAssassin. The reason you don’t want all those DNSBLs there is because not all of them are super accurate (some are too aggressive), which is why they’re in the SpamAssassin rules instead.
Basically the DNSBL list for Cloudron should only be if you want anything that has a hit to be outright rejected and never arrive in your mailbox (not even the junk folder). I prefer to keep that to just Abusix and SpamHaus myself because they have proven to be very accurate in the sense that they return no false positives, so they’re “safe” in rejecting only the most obvious of spam.
Then everything else that passes through that part will simply be scanned by SpamAssassin against the other DNSBLs in the custom rules and are therefore not rejected but just categorized as either spam or ham. It’s safer that way.
But also totally up to you. If you trust the other DNSBLs, then certainly feel free to add them to the Cloudron DNSBL list, but just know that doing so will most likely result in rejected/dropped messages that you’ll never know about until you look at the mail sever logs.
Ultimately… the DNSBLs in the custom SpamAssassin rule set doesn’t really have anything to do with the DNSBL setting used in Cloudron, as they are different levels of filtering and unrelated to each other.
Hopefully that makes sense. I’m just waking up while writing this so let me know if I can clarify further as I may not be explaining myself perfectly, lol.
Update: I think the theory on the plugin name change was the right area.
In the Cloudron SSO plugin, I changed this line (line 27 in cloudron-sso.php):
* Requires Plugins: openid-connect-generic
to be this instead...
* Requires Plugins: daggerhart-openid-connect-generic
Then I was able to enable the Cloudron SSO plugin and this resolved the issue, I was able to login again via SSO.
Tagging @girish for visibility.
Been having this same issue. It seems like WordPress app package was updated with the new plugin version, but the Plugin list didn't update so I figured it'd be okay to update it manually now that the new image was used, however it still seemed to break where the Cloudron SSO was showing as unable to be used since it's dependency was inactive or removed.
I disabled the OIDC plugin and Cloudron SSO in the hopes of sort of re-triggering its usage but it just fails to load the Cloudron SSO now all together. I noticed the folder name changed for the openid-connect plugin, in case that is part of the root cause. It used to be named openid-connect-generic (which is what Cloudron SSO is referring to still), and now it's daggerhart-openid-connect-generic. So I suppose the Cloudron SSO just needs to be pointing to daggerhart-openid-connect-generic instead now?
Looks really interesting!
Quick question: Do you find yourself paying for Claude Max, or Claude Pro, or just use API calls only for a pay-as-you-go (not necessarily for this project but just in general)? I was a ChatGPT Plus subscriber and while it has some nice features that Claude doesn’t have which make my life a bit easier compared to if I only used Claude web/desktop, in my testing I do enjoy Claude’s answers so much better in most cases. But the limits they have on their Pro plan I run into constantly so I think I need Max but it’s hard to justify that significant increase in cost. I wish they had something in the middle.
@IniBudi Yes just copy & paste, but remember to replace the API key for Abusix if you want to use Abusix (otherwise just remove the section for Abusix). Everything else is good to copy & paste. 
@murgero Thank you so much!
For the manual spam training, I find the script I shared earlier tends to work well for me, it's been helping me on my inbox at least when it comes to the BAYES scores it assigns to messages.
It takes a while though I found before I started noticing real benefits from it, so you likely need to run it several times (maybe a week or two apart each time) before it seems to really become smarter.
Cleaning backups in 9.0.13 doesn't seem to remove the .backupinfo files associated with the new backup integrity features of 9.0.
In my case, the backups are encrypted, in case that makes any difference to how the backup info files are generated. So the files are something like app_<app_name>_v3.11.5.tar.gz.enc.backupinfo. I have many of these files remaining after cleaning up some backups. The larger backups are gone as expected thankfully, but the backup info files remain.
I use a s3 backend for my backups (iDrive e3 specifically).
.backupinfo files.
Decided to leave an early Christmas present here for everyone 
I have an updated list of SpamAssassin rules I've been analyzing and running with for the past few months. According to my data (and helpful analysis from ChatGPT), this gives me about a 97% accuracy rate in my own mailbox at least. The remaining percentage was mostly from Bayesian learning rather than any particular score that could change the results, so running more spam training seemed to help smooth it out after a while.
A kind reminder... your mileage may vary as this is tested only with the spam that myself and other users on my Cloudron instance tend to receive, so it may not be as effective on your own mailboxes, but this should definitely help improve accuracy on spam detection especially for those who aren't yet using any tweaked SpamAssassin rules. Enjoy. 
Oh and remember to replace {redacted} with your own API key for Abusix if you are using Abusix like I am. If you're not, then just remove or comment-out those lines from the rules below.
# ============================
# Bayesian Filtering (BAYES)
# ============================
bayes_auto_learn 1
bayes_auto_learn_threshold_nonspam -3.0
bayes_auto_learn_threshold_spam 10.0
score BAYES_00 -7.0
score BAYES_05 -4.0
score BAYES_20 -1.0
score BAYES_40 0.5
score BAYES_50 0.75
score BAYES_60 2.25
score BAYES_80 3.75
score BAYES_95 6.5
score BAYES_99 8.0
score BAYES_999 8.5
# ============================
# DNS-based Blocklists (DNSBL)
# ============================
score RCVD_IN_BL_SPAMCOP_NET 4.0
score RCVD_IN_IADB_DK 0.0
score RCVD_IN_IADB_DOPTIN_LT50 0.0
score RCVD_IN_IADB_LISTED 0.0
score RCVD_IN_IADB_RDNS -0.25
score RCVD_IN_IADB_SENDERID -0.25
score RCVD_IN_IADB_SPF -0.25
score RCVD_IN_MSPIKE_BL 0.0
score RCVD_IN_MSPIKE_L2 1.0
score RCVD_IN_MSPIKE_L3 1.5
score RCVD_IN_MSPIKE_L4 3.5
score RCVD_IN_MSPIKE_L5 4.0
score RCVD_IN_MSPIKE_ZBI 4.0
score RCVD_IN_PBL 5.5
score RCVD_IN_PSBL 4.0
score RCVD_IN_SBL 5.0
score RCVD_IN_SBL_CSS 5.0
score RCVD_IN_VALIDITY_CERTIFIED 0.0
score RCVD_IN_VALIDITY_RPBL 0.0
score RCVD_IN_VALIDITY_SAFE 0.0
score RCVD_IN_XBL 6.5
score RCVD_IN_ZEN_BLOCKED 0.0
score RCVD_IN_ZEN_BLOCKED_OPENDNS 0.0
## DNS Whitelists
score RCVD_IN_DNSWL_BLOCKED 0.0
score RCVD_IN_DNSWL_HI -6.0
score RCVD_IN_DNSWL_LOW -1.0
score RCVD_IN_DNSWL_MED -4.5
score RCVD_IN_DNSWL_NONE 0.0
score RCVD_IN_MSPIKE_H2 0.0
score RCVD_IN_MSPIKE_H3 -0.25
score RCVD_IN_MSPIKE_H4 -0.5
score RCVD_IN_MSPIKE_H5 -1.0
score RCVD_IN_MSPIKE_WL 0.0
# ============================
# URI Blocklists (URIBL)
# ============================
score URIBL_ABUSE_SURBL 6.5
score URIBL_BLACK 5.0
score URIBL_CR_SURBL 3.5
score URIBL_CSS 3.0
score URIBL_CSS_A 5.0
score URIBL_DBL_ABUSE_BOTCC 5.5
score URIBL_DBL_ABUSE_MALW 5.5
score URIBL_DBL_ABUSE_PHISH 5.5
score URIBL_DBL_ABUSE_REDIR 2.0
score URIBL_DBL_ABUSE_SPAM 5.5
score URIBL_DBL_BLOCKED 0.0
score URIBL_DBL_BLOCKED_OPENDNS 0.0
score URIBL_DBL_BOTNETCC 5.5
score URIBL_DBL_ERROR 0.0
score URIBL_DBL_MALWARE 5.0
score URIBL_DBL_PHISH 6.0
score URIBL_DBL_SPAM 6.0
score URIBL_GREY 0.25
score URIBL_MW_SURBL 5.0
score URIBL_PH_SURBL 5.0
score URIBL_RED 2.0
score URIBL_RHS_DOB 2.0
score URIBL_SBL 4.0
score URIBL_SBL_A 3.0
score URIBL_ZEN_BLOCKED 0.0
score URIBL_ZEN_BLOCKED_OPENDNS 0.0
# ============================
# Email Authentication (SPF/DKIM/ARC)
# ============================
score ARC_INVALID 2.0
score ARC_SIGNED 0.0
score ARC_VALID 0.0
score DKIM_ADSP_ALL 2.0
score DKIM_ADSP_CUSTOM_MED 1.5
score DKIM_ADSP_NXDOMAIN 4.5
score DKIM_INVALID 2.0
score DKIM_SIGNED 0.0
score DKIM_VALID 0.0
score DKIM_VALID_AU 0.0
score DKIM_VALID_EF 0.0
score DKIM_VERIFIED 0.0
score DKIMWL_BL 3.0
score DKIMWL_WL_HIGH -6.5
score DKIMWL_WL_MED -4.5
score DKIMWL_WL_MEDHI -5.0
score FORGED_SPF_HELO 4.0
score NML_ADSP_CUSTOM_MED 2.0
score SPF_FAIL 3.0
score SPF_HELO_FAIL 3.0
score SPF_HELO_NEUTRAL 1.0
score SPF_HELO_NONE 0.0
score SPF_HELO_PASS -0.25
score SPF_HELO_SOFTFAIL 4.0
score SPF_NEUTRAL 0.0
score SPF_NONE 1.0
score SPF_PASS 0.0
score SPF_SOFTFAIL 1.5
score T_SPF_HELO_PERMERROR 0.0
score T_SPF_HELO_TEMPERROR 0.0
score T_SPF_PERMERROR 0.0
score T_SPF_TEMPERROR 0.0
score USER_IN_DEF_DKIM_WL -6.5
score USER_IN_DEF_SPF_WL -6.5
# ============================
# HTML & MIME Structure Rules
# ============================
score BODY_URI_ONLY 3.5
score DC_PNG_UNO_LARGO 1.5
score HTML_FONT_LOW_CONTRAST 0.0
score HTML_FONT_SIZE_LARGE 2.0
score HTML_FONT_TINY_NORDNS 0.0
score HTML_IMAGE_ONLY_04 2.0
score HTML_IMAGE_ONLY_08 2.0
score HTML_IMAGE_ONLY_12 2.0
score HTML_IMAGE_ONLY_16 2.0
score HTML_IMAGE_ONLY_20 2.0
score HTML_IMAGE_ONLY_24 2.0
score HTML_IMAGE_ONLY_28 2.0
score HTML_IMAGE_ONLY_32 2.0
score HTML_IMAGE_RATIO_02 0.25
score HTML_IMAGE_RATIO_04 0.25
score HTML_IMAGE_RATIO_06 0.25
score HTML_IMAGE_RATIO_08 0.25
score HTML_MESSAGE 0.0
score HTML_MIME_NO_HTML_TAG 0.5
score HTML_OBFUSCATE_05_10 0.5
score HTML_OBFUSCATE_10_20 1.0
score HTML_OBFUSCATE_20_30 2.0
score HTML_OBFUSCATE_30_40 2.5
score HTML_OBFUSCATE_50_60 3.0
score HTML_OBFUSCATE_70_80 3.5
score HTML_OBFUSCATE_90_100 4.0
score HTML_SHORT_LINK_IMG_1 2.0
score HTML_SHORT_LINK_IMG_2 3.0
score HTML_SHORT_LINK_IMG_3 3.0
score HTML_TAG_BALANCE_CENTER 0.25
score MIME_BASE64_TEXT 1.25
score MIME_HEADER_CTYPE_ONLY 0.5
score MIME_HTML_MOSTLY 0.0
score MIME_HTML_ONLY 0.0
score MIME_QP_LONG_LINE 0.25
score MPART_ALT_DIFF 0.75
score MPART_ALT_DIFF_COUNT 0.5
score T_KAM_HTML_FONT_INVALID 0.25
score T_TVD_MIME_EPI 0.25
# ============================
# Header / Envelope Heuristics
# ============================
score HDRS_MISSP 4.0
score HEADER_FROM_DIFFERENT_DOMAINS 0.0
score HK_RANDOM_ENVFROM 3.0
score MAILING_LIST_MULTI 0.25
score MISSING_DATE 2.5
score MISSING_FROM 2.0
score MISSING_HB_SEP 2.0
score MISSING_HEADERS 6.0
score MISSING_MID 1.0
score MISSING_SUBJECT 1.0
score MSGID_OUTLOOK_INVALID 2.5
score NO_FM_NAME_IP_HOSTN 2.0
score REPLYTO_WITHOUT_TO_CC 2.5
score TO_NO_BRKTS_FROM_MSSP 2.5
score TO_NO_BRKTS_MSFT 2.5
score TVD_RCVD_IP 1.0
# ============================
# Freemail & Identity Rules
# ============================
score FORGED_GMAIL_RCVD 3.0
score FORGED_MUA_OUTLOOK 3.0
score FORGED_YAHOO_RCVD 3.0
score FREEMAIL_ENVFROM_END_DIGIT 0.75
score FREEMAIL_FORGED_REPLYTO 2.5
score FREEMAIL_FROM 0.0
score FREEMAIL_REPLY 0.5
score FREEMAIL_REPLYTO 2.25
score FREEMAIL_REPLYTO_END_DIGIT 0.0
score FROM_EXCESS_BASE64 2.5
score FROM_FMBLA_NEWDOM 2.5
score FROM_FMBLA_NEWDOM14 3.0
score FROM_FMBLA_NEWDOM28 2.5
score FROM_GOV_SPOOF 3.5
score FROM_LOCAL_DIGITS 1.5
score FROM_LOCAL_HEX 1.5
score FROM_LOCAL_NOVOWEL 1.5
score FROM_MISSP_EH_MATCH 3.0
score FROM_MISSP_SPF_FAIL 3.0
score FROM_MISSPACED 3.0
score FROM_NTLD_REPLY_FREEMAIL 3.0
score FROM_STARTS_WITH_NUMS 1.0
score FROM_SUSPICIOUS_NTLD 2.0
score FROM_SUSPICIOUS_NTLD_FP 2.0
score GB_FREEMAIL_DISPTO 3.5
score GB_FREEMAIL_DISPTO_NOTFREEM 3.5
score HK_NAME_MR_MRS 2.5
score HK_RANDOM_FROM 1.5
score UNDISC_FREEM 2.5
# ============================
# Scam, Phishing & Social Engineering
# ============================
score ADVANCE_FEE_2 3.0
score ADVANCE_FEE_2_NEW_FORM 3.0
score ADVANCE_FEE_2_NEW_MONEY 3.0
score ADVANCE_FEE_3 3.0
score ADVANCE_FEE_3_NEW 3.0
score ADVANCE_FEE_3_NEW_FORM 3.0
score ADVANCE_FEE_3_NEW_MONEY 3.0
score ADVANCE_FEE_4_NEW 3.0
score ADVANCE_FEE_5_NEW 3.0
score ADVANCE_FEE_5_NEW_FRM_MNY 3.0
score ADVANCE_FEE_5_NEW_MONEY 3.0
score BILLION_DOLLARS 1.0
score BITCOIN_DEADLINE 5.5
score BITCOIN_SPAM_03 5.5
score DEAR_FRIEND 2.0
score DEAR_SOMETHING 2.0
score DIET_1 1.0
score FUZZY_BITCOIN 2.5
score FUZZY_BTC_WALLET 2.5
score FUZZY_CLICK_HERE 1.5
score FUZZY_CREDIT 2.0
score FUZZY_IMPORTANT 2.5
score FUZZY_SECURITY 2.75
score FUZZY_UNSUBSCRIBE 1.0
score FUZZY_WALLET 2.0
score JOIN_MILLIONS 2.0
score LOTS_OF_MONEY 0.0
score MONEY_BACK 1.0
score NA_DOLLARS 1.0
score PDS_BTC_ID 4.0
score STOX_BOUND_090909_B 1.5
score SUBJ_ALL_CAPS 0.5
score SUBJ_AS_SEEN 0.75
score SUBJ_ATTENTION 1.5
score SUBJ_DOLLARS 0.25
score SUBJ_YOUR_DEBT 2.5
score SUBJ_YOUR_FAMILY 0.75
score THIS_AD 0.5
score TVD_PH_BODY_ACCOUNTS_PRE 2.0
score TVD_PH_BODY_META 1.5
score UNCLAIMED_MONEY 4.0
score URG_BIZ 1.5
score VFY_ACCT_NORDNS 3.0
# ============================
# Transport / Network Reputation Rules
# ============================
score CK_HELO_GENERIC 1.5
score HELO_DYNAMIC_IPADDR 3.0
score HELO_DYNAMIC_IPADDR2 3.0
score HELO_DYNAMIC_SPLIT_IP 2.0
score KHOP_HELO_FCRDNS 4.0
score NO_RDNS_DOTCOM_HELO 3.0
score PDS_BAD_THREAD_QP_64 1.5
score PDS_RDNS_DYNAMIC_FP 0.5
score RCVD_HELO_IP_MISMATCH 1.75
score RCVD_ILLEGAL_IP 4.0
score RDNS_DYNAMIC 3.5
score RDNS_LOCALHOST 3.5
score RDNS_NONE 3.5
score SPAMMY_XMAILER 2.75
score TBIRD_SUSP_MIME_BDRY 2.5
score UNPARSEABLE_RELAY 0.0
# ============================
# URI & Link Obfuscation
# ============================
score GOOG_REDIR_NORDNS 2.5
score HTTPS_HTTP_MISMATCH 1.5
score NORMAL_HTTP_TO_IP 3.0
score NUMERIC_HTTP_ADDR 3.0
score PDS_SHORT_SPOOFED_URL 3.0
score SENDGRID_REDIR 0.25
score T_PDS_OTHER_BAD_TLD 2.5
score TRACKER_ID 0.25
score URI_HEX 2.0
score URI_NO_WWW_BIZ_CGI 2.5
score URI_NO_WWW_INFO_CGI 2.5
score URI_NOVOWEL 0.5
score URI_OBFU_WWW 3.0
score URI_PHISH 6.5
score URI_TRUNCATED 3.0
score URI_WP_HACKED 6.0
score WEIRD_PORT 4.5
# ============================
# Miscellaneous Heuristics & Content Triggers
# ============================
score ALIBABA_IMG_NOT_RCVD_ALI 2.5
score BIGNUM_EMAILS_FREEM 2.5
score BIGNUM_EMAILS_MANY 2.5
score DATE_IN_FUTURE_06_12 2.5
score DATE_IN_PAST_03_06 2.5
score DATE_IN_PAST_06_12 2.5
score ENV_AND_HDR_SPF_MATCH -4.0
score FILL_THIS_FORM 0.5
score FILL_THIS_FORM_LONG 0.5
score INVESTMENT_ADVICE 0.5
score MALWARE_NORDNS 5.0
score PLING_QUERY 1.0
score SHOPIFY_IMG_NOT_RCVD_SFY 0.75
score STOX_REPLY_TYPE 2.0
score STOX_REPLY_TYPE_WITHOUT_QUOTES 3.0
score SUSPICIOUS_RECIPS 2.5
score T_FILL_THIS_FORM_SHORT 0.25
score T_REMOTE_IMAGE 0.25
score TVD_SPACE_RATIO_MINFP -0.25
# ============================
# Spam Eating Monkey DNSBL lists
# ============================
header RCVD_IN_SEM_BACKSCATTER eval:check_rbl('sembackscatter-lastexternal','backscatter.spameatingmonkey.net')
describe RCVD_IN_SEM_BACKSCATTER Received from an IP listed by Spam Eating Monkey Backscatter list
tflags RCVD_IN_SEM_BACKSCATTER net
score RCVD_IN_SEM_BACKSCATTER 3.0
header RCVD_IN_SEM_BLACK eval:check_rbl('semblack-lastexternal','bl.spameatingmonkey.net')
describe RCVD_IN_SEM_BLACK Received from an IP listed by Spam Eating Monkey Blocklist
tflags RCVD_IN_SEM_BLACK net
score RCVD_IN_SEM_BLACK 3.0
header RCVD_IN_SEM_NETBLACK eval:check_rbl('semnetblack-lastexternal','netbl.spameatingmonkey.net')
describe RCVD_IN_SEM_NETBLACK Received from an IP listed by Spam Eating Monkeys Network Blocklist
tflags RCVD_IN_SEM_NETBLACK net
score RCVD_IN_SEM_NETBLACK 1.5
urirhssub SEM_FRESH30 fresh30.spameatingmonkey.net. A 2
body SEM_FRESH30 eval:check_uridnsbl('SEM_FRESH30')
describe SEM_FRESH30 Contains a domain registered less than 30 days ago
tflags SEM_FRESH30 net
score SEM_FRESH30 3.0
urirhssub SEM_URI_BLACK uribl.spameatingmonkey.net. A 2
body SEM_URI_BLACK eval:check_uridnsbl('SEM_URI')
describe SEM_URI_BLACK Contains a URI listed by Spam Eating Monkeys URI Blocklist
tflags SEM_URI_BLACK net
score SEM_URI_BLACK 2.5
# ============================
# JunkEmailFilter HostKarma DNSBL & DNSWL
# ============================
header __RCVD_IN_HOSTKARMA eval:check_rbl('hostkarma','hostkarma.junkemailfilter.com.')
describe __RCVD_IN_HOSTKARMA Sender listed in JunkEmailFilter
tflags __RCVD_IN_HOSTKARMA net
header RCVD_IN_HOSTKARMA_BL eval:check_rbl_sub('hostkarma','127.0.0.2')
describe RCVD_IN_HOSTKARMA_BL Sender listed in HOSTKARMA-BLACK
tflags RCVD_IN_HOSTKARMA_BL net
score RCVD_IN_HOSTKARMA_BL 1.0
header RCVD_IN_HOSTKARMA_BR eval:check_rbl_sub('hostkarma','127.0.0.4')
describe RCVD_IN_HOSTKARMA_BR Sender listed in HOSTKARMA-BROWN
tflags RCVD_IN_HOSTKARMA_BR net
score RCVD_IN_HOSTKARMA_BR 0.5
header RCVD_IN_HOSTKARMA_W eval:check_rbl_sub('hostkarma','127.0.0.1')
describe RCVD_IN_HOSTKARMA_W Sender listed in HOSTKARMA-WHITE
tflags RCVD_IN_HOSTKARMA_W net nice
score RCVD_IN_HOSTKARMA_W -1.0
# ============================
# SpamRATS DNSBL
# ============================
header __RCVD_IN_SPAMRATS eval:check_rbl('spamrats','all.spamrats.com.')
describe __RCVD_IN_SPAMRATS SPAMRATS: sender is listed in SpamRATS
tflags __RCVD_IN_SPAMRATS net
reuse __RCVD_IN_SPAMRATS
header RCVD_IN_SPAMRATS_DYNA eval:check_rbl_sub('spamrats','127.0.0.36')
describe RCVD_IN_SPAMRATS_DYNA RATS-Dyna: sent directly from dynamic IP address
tflags RCVD_IN_SPAMRATS_DYNA net
reuse RCVD_IN_SPAMRATS_DYNA
score RCVD_IN_SPAMRATS_DYNA 2.25
header RCVD_IN_SPAMRATS_NOPTR eval:check_rbl_sub('spamrats','127.0.0.37')
describe RCVD_IN_SPAMRATS_NOPTR RATS-NoPtr: sender has no reverse DNS
tflags RCVD_IN_SPAMRATS_NOPTR net
reuse RCVD_IN_SPAMRATS_NOPTR
score RCVD_IN_SPAMRATS_NOPTR 2.5
header RCVD_IN_SPAMRATS_SPAM eval:check_rbl_sub('spamrats','127.0.0.38')
describe RCVD_IN_SPAMRATS_SPAM RATS-Spam: sender is a spam source
tflags RCVD_IN_SPAMRATS_SPAM net
reuse RCVD_IN_SPAMRATS_SPAM
score RCVD_IN_SPAMRATS_SPAM 4.5
# ============================
# UCEPROTECT
# ============================
header RCVD_IN_UCEPROTECT_LEVEL_1 eval:check_rbl('uceprotect1','dnsbl-1.uceprotect.net.')
describe RCVD_IN_UCEPROTECT_LEVEL_1 Sender IP listed in UCEPROTECT Level 1
tflags RCVD_IN_UCEPROTECT_LEVEL_1 net
score RCVD_IN_UCEPROTECT_LEVEL_1 3.0
header RCVD_IN_UCEPROTECT_LEVEL_2 eval:check_rbl('uceprotect2','dnsbl-2.uceprotect.net.')
describe RCVD_IN_UCEPROTECT_LEVEL_2 Sender IP listed in UCEPROTECT Level 2
tflags RCVD_IN_UCEPROTECT_LEVEL_2 net
score RCVD_IN_UCEPROTECT_LEVEL_2 2.5
# ============================
# Abusix Guardian Mail Relay
# ============================
header __RCVD_IN_ABUSIX eval:check_rbl('abusix','{redacted}.combined.mail.abusix.zone.')
describe __RCVD_IN_ABUSIX Received via a relay in Abusix Guardian Mail
tflags __RCVD_IN_ABUSIX net
header RCVD_IN_ABUSIX_BLACK eval:check_rbl_sub('abusix','^127\.0\.0\.(?:[23]|200)$')
describe RCVD_IN_ABUSIX_BLACK Received via a relay in Abusix Guardian Mail Black
tflags RCVD_IN_ABUSIX_BLACK net
score RCVD_IN_ABUSIX_BLACK 7.5
#header RCVD_IN_ABUSIX_EXPLOIT eval:check_rbl_sub('abusix','127.0.0.4')
#describe RCVD_IN_ABUSIX_EXPLOIT Received via a relay in Abusix Guardian Mail Exploit
#tflags RCVD_IN_ABUSIX_EXPLOIT net
#score RCVD_IN_ABUSIX_EXPLOIT 6.0
header RCVD_IN_ABUSIX_DYN eval:check_rbl('abusix_dyn','{redacted}.combined.mail.abusix.zone.','^127\.0\.0\.1[12]$')
describe RCVD_IN_ABUSIX_DYN Received via a relay in Abusix Guardian Mail Dynamic
tflags RCVD_IN_ABUSIX_DYN net
score RCVD_IN_ABUSIX_DYN 2.0
header RCVD_IN_ABUSIX_WHITE eval:check_rbl('abusix_white','{redacted}.combined.mail.abusix.zone.','127.0.2.1')
describe RCVD_IN_ABUSIX_WHITE Received via a relay in Abusix Guardian Mail White
tflags RCVD_IN_ABUSIX_WHITE nice net
score RCVD_IN_ABUSIX_WHITE -1.5
urirhsbl URIBL_ABUSIX_DBLACK {redacted}.dblack.mail.abusix.zone. A
body URIBL_ABUSIX_DBLACK eval:check_uridnsbl('URIBL_ABUSIX_DBLACK')
describe URIBL_ABUSIX_DBLACK Contains a spam URL listed in the Abusix domain blocklist
tflags URIBL_ABUSIX_DBLACK net
score URIBL_ABUSIX_DBLACK 7.5
urirhssub URIBL_ABUSIX_WHITE {redacted}.white.mail.abusix.zone. A 127.0.2.1
body URIBL_ABUSIX_WHITE eval:check_uridnsbl('URIBL_ABUSIX_WHITE')
describe URIBL_ABUSIX_WHITE Contains a domain listed in the Abusix domain whitelist
tflags URIBL_ABUSIX_WHITE nice net
score URIBL_ABUSIX_WHITE -0.25
# ============================
# Ascams RBLs (IP Reputation)
# ============================
header RCVD_IN_ASCAMS_BLOCK eval:check_rbl('ascams_block','block.ascams.com.')
describe RCVD_IN_ASCAMS_BLOCK Sender listed in Ascams Block RBL
tflags RCVD_IN_ASCAMS_BLOCK net
score RCVD_IN_ASCAMS_BLOCK 0.0
header RCVD_IN_ASCAMS_DROP eval:check_rbl('ascams_white','dnsbl.ascams.com.')
describe RCVD_IN_ASCAMS_DROP Sender listed in Ascams DROP list
tflags RCVD_IN_ASCAMS_DROP nice net
score RCVD_IN_ASCAMS_DROP 3.5
# ============================
# DroneBL DNSBL
# ============================
header RCVD_IN_DRONEBL eval:check_rbl('dronebl','dnsbl.dronebl.org.')
describe RCVD_IN_DRONEBL Sender listed in DroneBL (suspected bot/malware)
tflags RCVD_IN_DRONEBL net
score RCVD_IN_DRONEBL 2.0
# ============================
# GBUDB Truncate DNSBL
# ============================
header RCVD_IN_GBUDB_TRUNCATE eval:check_rbl('gbudb','truncate.gbudb.net.')
describe RCVD_IN_GBUDB_TRUNCATE Sender listed in GBUDB Truncate
tflags RCVD_IN_GBUDB_TRUNCATE net
score RCVD_IN_GBUDB_TRUNCATE 5.0
# ============================
# Usenix S5H
# ============================
header RCVD_IN_S5H_BL eval:check_rbl_txt('s5hbl','all.s5h.net.')
describe RCVD_IN_S5H_BL Listed at all.s5h.net
tflags RCVD_IN_S5H_BL net
score RCVD_IN_S5H_BL 1.5
# ============================
# Backscatterer.org
# ============================
header RCVD_IN_BACKSCATTERER eval:check_rbl('backscatterer','ips.backscatterer.org.')
describe RCVD_IN_BACKSCATTERER IP listed in Backscatterer (backscatter spam)
tflags RCVD_IN_BACKSCATTERER net
score RCVD_IN_BACKSCATTERER 2.25
@girish , I guess I look at it from the perspective of... if the host/vendor didn't bother to set up those details in the firmware of the BIOS, then why does it show in the System view for Cloudron? At that point, it's just unnecessary noise, isn't it? How does To Be Filled By O.E.M. help a Cloudron administrator looking at the Server page?
I like the idea of being able to customize it as some users may find that helpful, however I'm certainly not fixated on it, so maybe instead of being able to customize it (if you prefer it not be customized), we could at least remove it/hide it from view when the value is the default/unset To Be Filled By O.E.M.?
I just dislike seeing those lines in there when they're not helpful because the vendor (OVH in my case) didn't set them in the firmware of the BIOS, and they're likely not willing to either. I had opened a case with them a couple of years back I think asking them to set it (thinking it was mistakenly overlooked), but they said because all their servers are basically custom built, they don't set those on their dedicated servers. I imagine it may not apply to all, but does for at least some of the dedicated servers OVH sells. I have to imagine OVH isn't the only one either selling dedicated servers without values set for product and vendor.
In my case, I wanted to set it the way I felt they should be set (Vendor = OVHcloud, Product = SYS-GAME-2), but if that's not desired by the community then maybe at least hiding it when it's unhelpful (i.e. the default/unset value) could be nice so that it doesn't seem like it's incorrectly configured.
Hopefully that makes sense.
That's a fair point about the REST API being commonly disabled, I hadn't fully considered that (I tend to disable XML-RPC and such but not normally the WP-JSON API, I guess I should look into doing that myself next too, haha).
Given that, what about using a simple HEAD request to / (the homepage) instead? This would:
I guess my concern is that the current manner in which the health check is done is not considered to be best practice (accessing PHP files directly, according to Patchstack at least), so I'm just trying to think of a better way to approach this that follows best practice.
So perhaps a HEAD request to the homepage may be the better option in this scenario? Since some people may have password protected sites and such, keeping the logic to consider anything that isn't a 5xx HTTP status response as "healthy" probably still makes plenty of sense here.
I'm happy to test any approaches too if that helps at all.
@Kubernetes said in Cloudron 9.0 (beta) bug reports:
Not sure if that already has been reported, but if I click on the refresh icon in the email event log page. the logs jump 2 hours back in time instead of refreshing to the current time.
Yes, that definitely happens to me too! Good catch, as I noticed it but forgot to report it. 
I’m glad you brought it up.
@Jenova said in Cloudron 9.0 (beta) bug reports:
Is it just me or is version 9 using way more memory? Like I swear I wasn't swapping with 1 GB of memory before this but it could just be that I didn't notice it?
I can’t say I’ve noticed any increased memory usage, for what that’s worth. 
Interesting if it is though.
Some VPS and dedicated server providers (OVH in my case) ship servers with placeholder DMI/SMBIOS information that shows as "To Be Filled By O.E.M." in the Server page of Cloudron. This information is read from /sys/devices/virtual/dmi/id/ and cannot be changed at the OS level since it's stored in read-only firmware. This results in some annoyances in the Server page when reviewing the details.
Current display in Cloudron Server page:
To Be Filled By O.E.M.To Be Filled By O.E.M.Add optional configuration fields to allow administrators to override the system vendor and product name displayed in Cloudron's Server page. This can help not only in allowing us to be more technically accurate, but also could be used by admins for quickly identifying prod vs stage servers, or the type of Cloudron server that's running if managing multiple for example.
Proposals:
Add optional fields to a Cloudron config file, for example /home/yellowtent/platformdata/configs/system.json:
{
"systemVendorOverride": "OVH",
"productNameOverride": "SYS-GAME-2"
}
Add fields in System → Settings or Server:
If these fields are populated, use them instead of the DMI values.
Allow setting via environment variables:
CLOUDRON_SYSTEM_VENDOR="OVH"
CLOUDRON_PRODUCT_NAME="SYS-GAME-2"
My preference would be option #2 above that's only editable by administrators.
The relevant code is in system.js in the getInfo() function:
async function getInfo() {
// ... existing code ...
const sysVendor = safe.fs.readFileSync('/sys/devices/virtual/dmi/id/sys_vendor', 'utf8') || '';
const productName = safe.fs.readFileSync('/sys/devices/virtual/dmi/id/product_name', 'utf8') || '';
// ... existing code ...
return {
sysVendor: sysVendor.trim(),
productName: productName.trim() || productFamily.trim(),
// ... other fields ...
};
}
This is related in part to https://forum.cloudron.io/post/81065. Between OVH's indifference to setting these BIOS firmware attributes, and my mild OCD... lol, I'm hoping we can add this as a small nice-to-have improvement for users.
@girish Thanks for the quick reply, that makes sense to me.
I’m not worried about Cloudron’s health logic itself; the main thing I’m running into is that the current path (/wp-includes/version.php) consistently triggers Patchstack because it resembles direct access to a core WordPress PHP file. That leads to a lot of blocked requests and noisy logs, even though the container is functioning normally.
Switching the health check to something like /wp-json/ would still meet Cloudron’s requirement (“anything non-5xx is healthy”), but it would avoid these false positives entirely. As a bonus, it also reflects more accurately that WordPress is actually up and running dynamic code.
I do already monitor sites externally, so no concerns there... this suggestion is more about the internal health check interacting unexpectedly with modern WordPress hardening tools. As these tools become more common, using an endpoint like /wp-json/ might help avoid similar issues for other users without changing Cloudron’s expectations for the liveness of an application like WordPress.
Hi team,
I’ve been digging into how the WordPress (Developer) app reports container health, and I noticed the check currently requests /wp-includes/version.php.
This seems to work functionally, but I’m running into an edge case where WP Umbrella’s Site Protect feature (which is really just Patchstack under the hood) flags these requests from the Docker bridge IP (172.18.0.1). Patchstack is treating direct access to php files as a security threat and it becomes blocked. This generated a 403 response in the application logs for the health check:
Dec 01 21:49:20 - - - [02/Dec/2025:05:49:20 +0000] "GET /wp-includes/version.php HTTP/1.1" 403 20171 "-" "Mozilla (CloudronHealth)"
(Side note: I am surprised that this doesn't trigger any issues in Cloudron. Shouldn't it expect a 200 response? Or is the logic perhaps anything that isn't a 5xx is treated as "healthy"? )
This got me thinking... is this current health check considered best practice? According to our AI overlords, lol, this is not the best health check endpoint and can trigger security concerns much like it does currently with Patchstack blocking direct access to the WordPress core php files.
Would it be possible to switch the health check endpoint to /wp-json/ instead of /wp-includes/version.php?
Reasons this might be a better option:
It still keeps things simple while being a bit more aligned with how WordPress expects to be probed.
If you ever want an explicit health endpoint, a tiny MU plugin exposing something like /wp-json/cloudron/v1/health and returning { "status": "OK" } could provide a dedicated probe that works cleanly in all environments. But /wp-json/ is more than adequate for now, I think.
If the goal is only to confirm the web server is responding, even a HEAD / check would avoid the security flags.
Happy to test anything on my end.
Thanks as always for all the work you do! Cloudron has been very solid in my environment and the latest improvements for 9.0 have been great to see.
@girish said in Attempted to restore Cloudron 9.0.12, receiving error when loading backup configuration and hitting Restore button:
@d19dotca I tried to reproduce this but I couldn't figure where to set this IP allowlist in iDrive e2. Maybe it's only for paying customers since I am on the trial plan ?
Hi Girish. This link can help, assuming it isn’t gated to paying customers (I’m not sure if it is or not), but hopefully this provides some instructions for setting up an allowlist.
https://www.idrive.com/s3-storage-e2/faq-buckets#ip-allowlisting
I suspect you’re right though, that it is sending back a non-XML response to provide a response message that it’s forbidden from accessing it. I understand this use-case may be rare, but I think if there’s a way to improve that error handling, it may help others too because at first glance it’s really not clear where the issue could be coming from.
Oh I fixed it. Embarrassingly, this was an issue on my side. I forgot I had added some IP allowlist to the iDrive e2 bucket which is what happened here. Once I added the new IP address, this all worked properly. Sorry about this. Hopefully this helps someone else in the future though. 
I do think the error message should be improved here though, it's a bit cryptic as it is currently.