@girish does this includes the email spam whitelist mentioned here with API and GUI?
https://forum.cloudron.io/topic/15310/spam-acl-whitelist-in-api-but-not-in-gui/

@p44 with the excellent help of @d19dotca in https://forum.cloudron.io/topic/4770/sharing-custom-spamassassin-rules I have been using his latest versions since 2021. With my three different Cloudrons (together 65 users and 92 mailboxes) the spam was reduced to about 7%.

However due to some glitches it made me ask ChatGPT for a review, below my version as of today and the explanation by ChatGPT why:

After using the initial ruleset in production, I adjusted the scores with one main goal: reduce false positives without weakening real spam/phishing detection.

Key Changes & Reasoning

1. DNSBL scores reduced slightly
   Some lists (e.g. PBL, SBL, XBL) were too dominant—one hit could almost classify a message as spam. Lowered them so they still matter, but now require supporting signals.
2. URIBL rebalanced
   Generic SURBL scores were reduced, while high-confidence Spamhaus DBL categories (phish/malware/botnet) remain strong. This avoids penalizing legitimate platforms with mixed reputation.
3. SPF/DKIM/DMARC normalized
   Lowered impact of SPF softfail (common with forwarding)
   Reduced trust in SPF/DKIM whitelists
   Added KAM rules for better DMARC/reputation context
4. HTML/content rules softened
   BODY_URI_ONLY reduced to avoid flagging legitimate newsletters and link-heavy emails.
5. Freemail & Reply-To tuning
   Lowered FREEMAIL_REPLYTO to reduce false positives from SaaS/CRM systems.
6. RDNS/network heuristics reduced
   Dynamic IP / missing rDNS is common in cloud setups, so these are now weaker signals.
7. Phishing & anomaly signals slightly tuned down
   High-risk rules (like URI_PHISH) still strong, but less likely to trigger on borderline cases.
8. Date anomalies reduced
   Time drift and header inconsistencies happen often in legitimate mail, so these are now low-weight.

Result

Less false positives (especially newsletters, SaaS, forwarded mail)
Spam now typically requires multiple signals instead of one strong hit
Phishing/malware detection remains solid
Overall, the system is now more balanced and closer to how modern email behaves.

# ============================
# Bayesian Filtering (BAYES)
# ============================

bayes_auto_learn 1
bayes_auto_learn_threshold_spam 6.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 4.0
score RCVD_IN_PSBL 4.0
score RCVD_IN_SBL 4.5
score RCVD_IN_SBL_CSS 3.5
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 5.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 -4.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 4.5
score URIBL_BLACK 4.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 3.5
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 -4.5
score DKIMWL_WL_MED -3.5
score DKIMWL_WL_MEDHI -4.0
score FORGED_SPF_HELO 4.0
score NML_ADSP_CUSTOM_MED 2.0
score SPF_FAIL 4.5
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.0
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 -4.5
score USER_IN_DEF_SPF_WL -4.0
score DMARC_FAIL 5.0
score KAM_DMARC_STATUS 2.0
score KAM_SHORT 1.5
score KAM_DMARC_REJECT 3.5
score KAM_DMARC_QUARANTINE 2.5
score KAM_REPUTATION 2.0

# ============================
# HTML & MIME Structure Rules
# ============================

score BODY_URI_ONLY 2.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 1.0
score HTML_IMAGE_ONLY_08 1.5
score HTML_IMAGE_ONLY_16 2.5
score HTML_IMAGE_ONLY_24 3.5
score HTML_IMAGE_ONLY_32 4.5
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 3.5
score FREEMAIL_FROM 0.0
score FREEMAIL_REPLY 0.5
score FREEMAIL_REPLYTO 1.75
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 4.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 2.5
score RDNS_LOCALHOST 3.5
score RDNS_NONE 2.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 5.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 1.5
score DATE_IN_PAST_03_06 1.5
score DATE_IN_PAST_06_12 1.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.5

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



# ============================
# 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

@james said:

Could you validate if your custom Spamassassin rules work?

I guess it works, the rules before did a good job, the edits were minor tweaks and since then there are not more than before spam (actually it's still quite low).

I just edited the Custom Spamassassin rules and with saving the logs says below, is this normal, does it work?

Apr 14 11:57:51 [POST] /spam_acl
Apr 14 11:57:51 2026-04-14 09:57:51,747 INFO waiting for spamd to stop
Apr 14 11:57:51 2026-04-14 09:57:51,787 INFO stopped: spamd (exit status 0)
Apr 14 11:57:51 2026-04-14 09:57:51,787 INFO reaped unknown pid 97370 (terminated by SIGINT)
Apr 14 11:57:51 2026-04-14 09:57:51,787 INFO reaped unknown pid 97371 (terminated by SIGINT)
Apr 14 11:57:51 2026-04-14 09:57:51,790 INFO spawned: 'spamd' with pid 98084
Apr 14 11:57:52 2026-04-14 09:57:52,792 INFO success: spamd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Apr 14 11:57:52 [POST] /spam_custom_config
Apr 14 11:57:53 Apr 14 09:57:53.363 [98087] warn: config: path "/root/.spamassassin" is inaccessible: Permission denied
Apr 14 11:57:53 Apr 14 09:57:53.363 [98087] warn: config: path "/root/.spamassassin/user_prefs" is inaccessible: Permission denied
Apr 14 11:57:53 Apr 14 09:57:53.436 [98087] warn: config: registryboundaries: no tlds defined, need to run sa-update
Apr 14 11:57:53 Apr 14 09:57:53.445 [98087] warn: config: path "/root/.spamassassin" is inaccessible: Permission denied
Apr 14 11:57:53 2026-04-14 09:57:53,643 INFO waiting for spamd to stop
Apr 14 11:57:53 2026-04-14 09:57:53,699 INFO stopped: spamd (exit status 0)
Apr 14 11:57:53 2026-04-14 09:57:53,703 INFO spawned: 'spamd' with pid 98090
Apr 14 11:57:54 2026-04-14 09:57:54,706 INFO success: spamd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

https://forum.cloudron.io/topic/15310/spam-acl-whitelist-in-api-but-not-in-gui/

@girish main question is if it will be officially supported (at least in API) as it was meant to be?

@girish said:

@imc67 for the moment, it's best not to use allowlist. It's not exposed in UI because it's not really tested or working well. Currently, all it does it add anything in allowlist to SpamAssassin's whitelist_auth - https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html .

Thanks for sharing this information, though I really would like to see this working officially because currently there is no way to “force allow” emails that gets into spam unneeded.

@tobiasb I know about the “blacklist” but I was looking for the “whitelist” with email addresses

In this doc: https://docs.cloudron.io/api/download-system-logs

its written:

Systemd unit name (e.g., box, nginx, mysql).

however:

# curl -s "https://my.***.nl/api/v1/system/logs/nginx?access_token=***" | head -5
{
  "status": "Bad Request",
  "message": "No such unit 'nginx'"
}

# curl -s "https://my.***.nl/api/v1/system/logs/box?access_token=***" | head -5
{"realtimeTimestamp":1774683967027000,"message":"apphealthmonitor: setHealth: 3028ad69-1c5f-44c7-ae4c-f61a3f194df3 (***redacted***) waiting for 1186.973 to update health","source":"box"}

# curl -s "https://my.***.nl/api/v1/system/logs/mysql?access_token=***" | head -5
{
  "status": "Bad Request",
  "message": "No such unit 'mysql'"
}

Because of the fact that Cloudron is not logging any 'failed logins' in the box.log (except succeeded) I need to extract them from the NGINX logs but then the API must work.
p.s.: the stream version does work but is not really suitable

@james said:

Hello @imc67
Fixed.

I'm really curious what you've fixed because the link docs link in the app still results in a 404: https://docs.cloudron.io/packages/ip2location

In the meanwhile I discovered the app previously was named GeoIP and can be found here https://docs.cloudron.io/packages/geoip/

I just installed IP2Location and clicked the docs link:

https://docs.cloudron.io/packages/ip2location

But there is a 404 and no documentation about this app. Is it still functioning and how is the internal database updated? How does it work?

I'm building an external (multi) Cloudron Security Monitoring app and I am very exited about all the API possibilities!

One thing I noticed in https://docs.cloudron.io/api/get-spam-acl

APPLICATION/JSON
Schema
Example (auto)
SCHEMA
whitelist
string[]
List of email addresses that are allowed (whitelisted).
Example: ["no-spam@mail.de"]
blacklist
string[]
List of email addresses that are blocked (blacklisted).
Example: ["spam@mail.de"]

However I can't find the whitelisted email addresses in the Cloudron GUI, or am I wrong?

wow that is fast, Thanks!

O what a pity was hoping this could be a solution

@girish I don't know if this I related but it's the first time I tried: cloudron-support --troubleshoot and this is the result, a [FAIL] that can't be solved AND it's exactly the same on my 2 other servers....:

root@xxx:~# cloudron-support --troubleshoot
Vendor: netcup Product: KVM Server
Linux: 5.15.0-171-generic
Ubuntu: jammy 22.04
Execution environment: kvm
Processor: AMD EPYC 7702P 64-Core Processor x 10
RAM: 65842976KB
Disk: /dev/sda3       1.9T
[OK]    node version is correct
[OK]    IPv6 is enabled and public IPv6 address is working
[OK]    docker is running
[OK]    docker version is correct
[OK]    MySQL is running
[OK]    netplan is good
[OK]    DNS is resolving via systemd-resolved
[OK]    unbound is running
[OK]    nginx is running
[OK]    dashboard cert is valid
[OK]    dashboard is reachable via loopback
[FAIL]  Database migrations are pending. Last migration in DB: /20260217120000-mailPasswords-create-table.js. Last migration file: /package.json.
        Please run 'cloudron-support --apply-db-migrations' to apply the migrations.
[OK]    Service 'mysql' is running and healthy
[OK]    Service 'postgresql' is running and healthy
[OK]    Service 'mongodb' is running and healthy
[OK]    Service 'mail' is running and healthy
[OK]    Service 'graphite' is running and healthy
[OK]    Service 'sftp' is running and healthy
[OK]    box v9.1.3 is running
[OK]    Dashboard is reachable via domain name
[WARN]  Domain xxx.nl expiry check skipped because whois does not have this information
root@xxx:~# cloudron-support --apply-db-migrations
Applying pending database migrations
2026-03-12T11:27:14 ==> start: Cloudron Start
media:x:500:
2026-03-12T11:27:14 ==> start: Configuring docker
Synchronizing state of apparmor.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable apparmor
2026-03-12T11:27:15 ==> start: Ensuring directories
2026-03-12T11:27:15 ==> start: Configuring journald
2026-03-12T11:27:15 ==> start: Setting up unbound
2026-03-12T11:27:15 ==> start: Adding systemd services
Synchronizing state of unbound.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable unbound
Synchronizing state of cron.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable cron
Synchronizing state of rpcbind.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable rpcbind
2026-03-12T11:28:39 ==> start: Configuring sudoers
2026-03-12T11:28:39 ==> start: Unconfiguring collectd
Synchronizing state of collectd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable collectd
2026-03-12T11:28:40 ==> start: Configuring logrotate
2026-03-12T11:28:40 ==> start: Adding motd message for admins
2026-03-12T11:28:40 ==> start: Configuring nginx
2026-03-12T11:28:41 ==> start: Starting mysql
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
2026-03-12T11:28:41 ==> start: Migrating data
[INFO] No migrations to run
[INFO] Done
2026-03-12T11:28:41 ==> start: Changing ownership
2026-03-12T11:28:41 ==> start: Starting cloudron-syslog
2026-03-12T11:28:41 ==> start: Starting Cloudron
2026-03-12T11:28:43 ==> start: Almost done
[OK]    Database migrations applied successfully
root@xxx:~# cloudron-support --troubleshoot
Vendor: netcup Product: KVM Server
Linux: 5.15.0-171-generic
Ubuntu: jammy 22.04
Execution environment: kvm
Processor: AMD EPYC 7702P 64-Core Processor x 10
RAM: 65842976KB
Disk: /dev/sda3       1.9T
[OK]    node version is correct
[OK]    IPv6 is enabled and public IPv6 address is working
[OK]    docker is running
[OK]    docker version is correct
[OK]    MySQL is running
[OK]    netplan is good
[OK]    DNS is resolving via systemd-resolved
[OK]    unbound is running
[OK]    nginx is running
[OK]    dashboard cert is valid
[OK]    dashboard is reachable via loopback
[FAIL]  Database migrations are pending. Last migration in DB: /20260217120000-mailPasswords-create-table.js. Last migration file: /package.json.
        Please run 'cloudron-support --apply-db-migrations' to apply the migrations.
[OK]    Service 'mysql' is running and healthy
[OK]    Service 'postgresql' is running and healthy
[OK]    Service 'mongodb' is running and healthy
[OK]    Service 'mail' is running and healthy
[OK]    Service 'graphite' is running and healthy
[OK]    Service 'sftp' is running and healthy
[OK]    box v9.1.3 is running
[OK]    Dashboard is reachable via domain name
[WARN]  Domain xxx.nl expiry check skipped because whois does not have this information

Hi everyone,

Last night our MiroTalk SFU instance (v2.1.26, running on Cloudron) crashed due to a Node.js
out-of-memory error. I wanted to share my analysis in case others run into the same issue.

BTW: there was NOTHING in the Cloudron GUI log:

Time	Source	Details	
11 mrt 2026, 02:02	cron	App was updated to v2.6.10	
11 mrt 2026, 02:00	cron	Update started from v2.6.9 to v2.6.10

---

What happened

Around 04:40 UTC the container crashed hard with the following fatal error:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
Aborted (core dumped)

The Node.js process had been running for approximately 27.5 hours (~99,000 seconds according
to the GC log). At the time of the crash, the heap was sitting at ~251 MB with no room left
to grow. Cloudron's healthcheck detected the crash via ECONNREFUSED and automatically
restarted the container. After the restart at 04:41 UTC the app came back up normally.

---

Disk I/O spike

The Disk I/O graph showed a sharp spike around the time of the crash and restart:

• MiroTalk Read: 6.26 MB/s
• System Read: 5.85 MB/s
• System Write: 4.91 MB/s
• MiroTalk Write: 2.2 MB/s

This is consistent with Docker rebuilding the container, writing the core dump, and reloading
all Node modules on startup. The background system writes (~2 MB/s) throughout the night
appear normal (likely backups/log rotation).

---

Probable causes

1. Memory leak — the process grew steadily over ~27.5 hours until the heap was exhausted.
   This pattern is typical of a slow memory leak in the application itself.

2. Insufficient heap size — with 10 mediasoup workers configured, the default Node.js
   heap limit can be too low under sustained load.

3. OIDC discovery errors as a contributing factor — just before the crash, the logs show
   repeated Issuer.discover() failed errors because the OIDC provider (issuerBaseURL)
   was temporarily unreachable. Repeated failed discovery attempts can accumulate error
   objects and contribute to heap pressure.

AggregateError: Issuer.discover() failed.
OPError: expected 200 OK, got: 404 Not Found
RequestError: Timeout awaiting 'request' for 5000ms

---

Recommendations

Short term: Increase the Node.js heap limit by setting the following environment variable
in your MiroTalk configuration:

NODE_OPTIONS=--max-old-space-size=2048

Monitoring: Keep an eye on RAM usage over time. If memory grows steadily without ever
dropping, that confirms a leak in the app that should be reported upstream to the MiroTalk
developer.

OIDC stability: Make sure the OIDC provider endpoint is reliably reachable. On Cloudron
this appears to be the built-in auth (/openid). If discovery requests fail repeatedly and
are not properly cleaned up, they may contribute to memory growth.

---

Environment

Property	Value
MiroTalk SFU	v2.1.26
Node.js	22.14.0
Workers	10
Server RAM	62.79 GB
OS	Linux 5.15.0 x64
Platform	Cloudron (Docker container)

---

Has anyone else seen this OOM pattern with MiroTalk SFU? Curious whether it's related to a
specific feature (OIDC, recording, etc.) or just general heap growth over time.

@girish said:

value since the server last rebooted

I knew that from an earlier post, we took that in account

Here the Netcup graph and Cloudron GUI graph of the last 6 hours, exactly the same (server was rebooted 3 days ago no timestamp in the Server - System - Uptime)

---

Summary of extensive disk I/O investigation — findings and conclusions

After spending considerable time investigating the high disk I/O on my servers (with help from an Claude PRO AI assistant, especially for this issue I subscribed to PRO!), I want to share my findings for anyone else experiencing this issue.

Setup: 3 servers running Cloudron v9.1.3, Ubuntu 22.04. Server 1 (just to focus on one): 12 WordPress sites, Matomo, EspoCRM, FreeScout (2x), Roundcube, MiroTalk, Taiga, MainWP, Yourls, Surfer (2x). Constant write I/O of ~2.5 MB/s = ~347 GB/day.

Reference: Cloudron demo server (20 apps including Nextcloud, Matrix, Discourse) shows ~80 GB/day. My servers run 4-5x higher with lighter apps.

---

What we investigated and measured

• iotop analysis: Docker MySQL (messageb) and host MySQL are by far the largest writers
• MySQL general log analysis: mapped write distribution per table
• Tested innodb_flush_log_at_trx_commit = 2: changes the pattern (bursts instead of constant pressure) but total write volume unchanged
• Analyzed nginx access logs for suspicious traffic patterns
• Compared against Cloudron demo server

---

What was cleaned up (almost no impact)

• EspoCRM: deleted 244K jobs + 244K scheduled_job_log_records; set cleanupJobPeriod to 7 days
• WordPress actionscheduler_claims: deleted 130K rows
• Roundcube: reduced from 5 to 1 installation
• Matomo: adjusted session_gc_probability and login_cookie_expire; cleared accumulated sessions
• Wordfence: reduced live traffic table to 200 rows / 1 day, disabled audit logging
• MainWP: disabled uptime monitor addon and SSL monitor addon
• MainWP wp_mainwp_wp_logs: deleted 46,903 rows older than 30 days
• MainWP wp_mainwp_wp_logs_meta: deleted 141,682 orphaned records
• MainWP: disabled Network Activity logging

---

What was ruled out as significant I/O cause

• Matomo: stopped the app entirely → no measurable difference in I/O
• MainWP: one of the three servers has no MainWP but shows identical I/O pattern
• FreeScout: job tables are empty
• External scan traffic: all returning 404/301 from nginx, no database impact

---

What is proven but not fixable without Cloudron

• Matomo healthcheck bug: GET / triggers the LoginOIDC plugin on every health check (every 10 seconds), creating a new MySQL session each time → 8,640 new sessions per day per Matomo instance. Fix requires changing the health check endpoint from GET / to /matomo.js in the app package. This is a Cloudron-side fix. Reported separately in topic 15211.
• InnoDB configuration: innodb_log_file_size is only 48MB (causes very frequent checkpoints), innodb_flush_method is fsync. These settings are suboptimal for a write-heavy workload but are managed by Cloudron.
• go-carbon/Graphite: writes ~0.13 MB/s continuously for 814 whisper metric files — inherent to Cloudron's monitoring stack.

---

Conclusion

There is no single large cause. The high I/O is the sum of multiple Cloudron-internal mechanisms. Everything works correctly — no performance issues, no user impact. But for a server with relatively low user traffic, 347 GB/day of writes feels disproportionate, especially compared to the Cloudron demo server at ~80 GB/day.

Sharing this in case it helps others investigating the same issue.

before I started:

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|    26920 |
+----------+
1 row in set (0.01 sec)

I did your settings in #4 and #5, restarted the app

After that (with some intervals):

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|    17398 |
+----------+
1 row in set (0.01 sec)

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|    17399 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|    17395 |
+----------+
1 row in set (0.01 sec)

I see they keep "hanging" around that amount

I decided to clean it once manually to give it a clean start ..

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from session;
+----------+
| count(*) |
+----------+
|        4 |
+----------+
1 row in set (0.00 sec)

Here is a more complete analysis of the disk I/O across all 3 servers.

1. Cloudron Disk I/O graph (server 1, last 6 hours)

The graph shows a constant write baseline of ~2.5 MB/s, 24/7. The spike around 20:00 is the scheduled daily backup — completely normal. The total write of 646 GB over 2 days (~323 GB/day) is almost entirely this constant baseline, not user traffic or backups.

2. iotop breakdown (server 1, 1 minute measurement)

Docker MySQL (messageb):  48.62 MB/min  (~0.81 MB/s)
Host MySQL:               23.26 MB/min  (~0.39 MB/s)
go-carbon:                 9.34 MB/min  (~0.16 MB/s)
jbd2 (fs journal):         8.44 MB/min  (~0.14 MB/s)
systemd-journald:          4.37 MB/min  (~0.07 MB/s)
containerd:                2.02 MB/min  (~0.03 MB/s)
dockerd:                   1.13 MB/min  (~0.02 MB/s)
Total:                   ~97 MB/min    (~1.6 MB/s average)

Note: the average of ~1.6 MB/s is consistent with the graph baseline of ~2.5 MB/s when accounting for peaks and the fact that iotop measures a 1-minute window.

3. InnoDB write activity since last MySQL restart (all 3 servers)

	Server 1 (uptime 59 min)	Server 2 (uptime ~40h)	Server 3 (uptime ~40h)
Data written	2.13 GB	55.3 GB	63.5 GB
Effective write rate	~0.58 MB/s	~0.38 MB/s	~0.43 MB/s
Rows inserted/s	6.5	8.8	8.6
Rows updated/s	7.0	4.5	4.0
Log writes/s	28.7	23.6	18.0

All three servers show a consistent insert rate of ~6-9 rows/second in the Docker MySQL, matching exactly 1 new Matomo session every 10 seconds (= health check interval).

Conclusion

The Docker MySQL (~0.4-0.8 MB/s) is the largest single contributor, driven primarily by Matomo session inserts. The total observed disk I/O of 2-4 MB/s is the sum of multiple processes, with the constant Matomo session accumulation as the most significant and most easily fixable component.