Cloudron Forum

You should see a summary in the email header just after the X-Spam-Status one, which explains how it came to this (ham) score. This should looks something like this, with different scores of course: X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no * trust * [87.253.236.95 listed in list.dnswl.org] * 0.0 HTML_MESSAGE BODY: HTML included in message

@james Yes it’s technically a feature request. I only threw it in here since it seemed like Girish was already making adjustments to the filtering in the mail event log viewer. If you’re okay forking it to a feature request, that’s totally fine.

there are also some posts from @d19dotca a while back about fine tuning spam rules

@timbo I have practically zero spam with the rules mentioned in my post and abusix DSNBL (https://abusix.com/) - the free tier is sufficient. Do you have catch-all enabled?

@necrevistonnezr said in MXtoolbox: Which site? Sorry, I forgot to include the link. I have updated the post now. mxtoolbox

@d19dotca right, the 30d one seems to be 54975 size. I have increased the size of the ipset now to 262144 elements. If these things are growing more, we can look into making this size dynamic .

@THI_Staff Apologies for a late response on this. I haven't used this yet. I was grandfathered on some free monitoring elsewhere. That being said, some of the delivery reports tell you servers that attempted to send email on your behalf. That has helped me resolve some delivery issues where others were sending legitimate emails, but using one of our email addresses instead of theirs. That tripped a DMARC fail. I would start their service without and then see if you want more.

@MisterJD yeah, I have seen that some kernels have an upper limit. I haven't found a way to query this limit to show a proper error.

Generally, we are able to manage posts which have spam content. Most existing users, they are quite benign. I think we are lucky so far with that we do little to no moderation (maybe only fixing some typos and moving to the right category) In this specific case, the issue was the profile page had spam content. This is a bit more elaborate and I am not sure how @SPRADEEP even came across it. I think if we have a script to clean up profiles which are over 2 weeks old and have not posted anything and have some junk profile, we can delete them. I can't imagine it's hard to spot junk in profiles with some basic word matching.

@girish Cloudron shows IP as present on Sorbs dnsbl blocklist, even though it isn't. [image: 1708555984912-2024-02-21_17-52-31.png] [image: 1708556022108-2024-02-21_17-53-31.png] Turns out I was too impatient, checks all green now.

Good notes to follow up when we look into email in the next release. IIRC, whitelist setting is a bit dangerous because it allows "spoofed" emails as it pretty much bypasses all the SPF/DMARC/DKIM checks. Meaning, Cloudron does not reject mail if those checks do not pass because there are too many misconfigured mail servers out there. Instead we tag the failures and allow spamassassin to score the rules. whitelisting makes spamassassin bypass the checks altogether.

@d19dotca Sadly, they do match. I'm guessing it's something with my current setup that's acting funny. I'll ignore it for now since I plan on migrating either to the new Contabo server that I got or upgrading my current one at DO to Ubuntu 20.04. I just thought it was a wrong setting on my part. Thank you for looking into this and for sharing the custom spam rules! I know you've put a lot of time into that [image: 1620396102638-2443c4d7-ec13-4149-add3-28e1e7ad48ed-image.png]

I end this thread because I now have a more specific one going.

@girish said in Anyone else see many connections denied due to "Mail from domain <domain> is not allowed from your host" repeatedly from spammy IPs?: @necrevistonnezr Ah, sorry! I misread. In my case, the sender is just spamming the hell out of me for video content. Sender is not trying to spoof. I guess you have to block by IP in the network firewall. Yeah, well, those IPs are never the same (see above) and even ranges are difficult to ascertain. Maybe an easy way to subscribe to a blocklist would help? (as suggested in my old topic linked above…)

@humptydumpty That's something I'd like to look into too, although I have a feeling the only thing that can really work its magic there is the Bayesian learning, so running the SpamAssassin learn commands. I've been running a script (with the help of ChatGPT, lol) like one below in case this helps as I find the Bayesian learning in Cloudron seems to be really manual or inconsistent at running (I think they've admitted that too in a post I saw somewhere the other month), and it's improved IMO with running this often. Personally I run this manually for now just because I wanted to make sure it was working, but I'll probably consider throwing this in a cron job soon enough. sudo docker exec -ti mail /bin/bash Run this script in the mail container: nohup bash -c ' MAILDIR="/app/data/vmail"; SPAMD_DIR="/app/data/spamd"; for user in $(ls "$MAILDIR"); do MAILBOX="$MAILDIR/$user/mail"; BAYES_PATH="$SPAMD_DIR/$user"; mkdir -p "$BAYES_PATH"; chown -R cloudron:cloudron "$BAYES_PATH"; chmod 700 "$BAYES_PATH"; echo "🔄 Training SpamAssassin for $user..." | tee -a /app/data/spamd/train.log; # Train spam from .Spam and .Junk folders (including subfolders) find "$MAILBOX/.Spam" "$MAILBOX/.Junk" -type d -name "cur" 2>/dev/null | while read folder; do echo "📂 Training SPAM from: $folder" | tee -a /app/data/spamd/train.log; sa-learn --spam --dbpath "$BAYES_PATH" --dir "$folder" | tee -a /app/data/spamd/train.log; done # Train ham from Inbox and Archive, but EXCLUDE Junk, Spam, Trash, Sent, and Drafts find "$MAILBOX" -type d -name "cur" 2>/dev/null | grep -Ev "/(\.Trash|\.Deleted Messages|\.Sent|\.Sent Messages|\.Drafts|\.Junk|\.Spam)/" | while read folder; do echo "📂 Training HAM from: $folder" | tee -a /app/data/spamd/train.log; sa-learn --ham --dbpath "$BAYES_PATH" --dir "$folder" | tee -a /app/data/spamd/train.log; done echo "✔ Completed training for $user! BAYES files stored in $BAYES_PATH" | tee -a /app/data/spamd/train.log; done; echo "🎉 SpamAssassin training completed for all mailboxes." | tee -a /app/data/spamd/train.log; ' > /app/data/spamd/train.log 2>&1 & It creates that train.log file and writes all the output to it so you can see it learning across all mailboxes for the Inbox and Archive folder as ham and the Junk/Spam folder as spam for all users. It's neat to see it saying it learned ham from 34 messages or something like that for each mailbox, haha. I think my latest spam rules are doing well the past week, so I'll likely be posting them here soon.

There is a "Spam" filter type in next release - 6.4

Okay... I may be on the side of this working properly again. lol. Maybe I've been wrong this whole time in thinking it wasn't working correctly. So coincidentally I was checking the mail server logs and saw another example of the same message go through to the same recipient from the same mail server, it was listed in the logs as "just now" so I quickly checked mxtoolbox and found that only 4 at that time had been listed, none of which were ones I was using. Here is how it looked at the very moment I checked when it was "just now" in the logs: [image: 1616004904806-69bc5a02-12ca-420e-958a-27405c21f7ed-image-resized.png] [image: 1616004923806-07b937c4-4840-4c14-887b-7513acc87251-image-resized.png] Edit: Checking about 6 minutes later, I see the blocklists have aleady been updated for more (Spamhaus Zen in this case would have caught it if it were about 5 minutes earlier): [image: 1616005021879-4522d168-dc21-498f-845b-885cfe0a73a1-image-resized.png] So I guess we can probably mark this as resolved, as I now see conclusive evidence that the various blocklists used just didn't have it listed until a few minutes after the message was received. I guess in order for it to adapt so quickly this spam attack on one of my users from those mail servers must be right at the beginning of a spam wave. Kind of neat actually to see how real-time these lists are. haha.

@girish - this is not possible to do unfortunately in Cloudron it seems, but kindly tell me if I'm doing something wrong here. The redirect works for filtering out spam, in other words only non-spam messages get through to the endpoint email using a filter like this: # rule:[Forward non-spam messages] if allof (not header :contains "x-spam-status" "Yes,") { redirect "<externalEmailAddress>"; } However, all messages marked as spam still save in the mailbox regardless of any filters I set to discard them. In my case, I want the spam messages to be discarded/deleted automatically as there's no sense in them remaining in the "forwarding only" mailbox. It seems maybe there's a priority filter going on elsewhere in Cloudron that's overriding my sieve filter? Using a filter like this: # rule:[Discard spam messages on arrival] if allof (header :contains "x-spam-status" "Yes,") { discard; stop; } ... will still save the email in the Spam folder. I've tried variations of it too but no-dice. Basically I can't get any filters to work when it's an identified spam message, only filters when it's NOT spam. Here's a way to reproduce it: Set this filter in Roundcube: # rule:[Discard spam messages on arrival] if allof (header :contains "x-spam-status" "Yes,") { discard; stop; } Send a message to the email account using the GTUBE string which SpamAssassin automatically marks with 1000 points, it's basically a test for spam filters: XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X See if the message is really discarded per the sieve filter or if it's still arriving in the Spam folder. In my cases, they still arrive in the Spam folder which seems to be incorrect behaviour. Edit: I wrote a dedicated bug for this instead: https://forum.cloudron.io/topic/5189/can-t-discard-spam-messages-on-arrival-using-sieve-filters/1