Raspberry Pi Email Server Part 4: Spam Detection with Spamassassin

Spamassassin Logo

This is the fourth part of a five part tutorial that will show you how to install a full featured email server on your Raspberry Pi. This tutorial covers how to mark emails as spam with Spamassassin.

The parts are:
The Introduction & Contents Page (read first)
Raspberry Pi Email Server Part 1: Postfix
Raspberry Pi Email Server Part 2: Dovecot
Raspberry Pi Email Server Part 3: Squirrelmail
Raspberry Pi Email Server Part 4: Spam Detection with Spamassassin
Raspberry Pi Email Server Part 5: Spam Sorting with LMTP & Sieve

Intro

I don’t actually get very many spam emails (famous last words, right?) but the occasional email gets past my helo access restrictions list (discussed in Raspberry Pi Email Server Part 1: Postfix).

So, I decided to set up Spamassassin, a program that will check incoming emails and mark them as spam if they look suspicious. Spamassassin is pretty clever, it uses bayesian filtering to decide what’s spam and what’s not, and it will learn based on previous results, so it gets more accurate over time if you correct it when it gets things wrong.

Spamassassin will only mark emails as spam, it will not sort them into folders for you as well. We’ll be doing the sorting with Dovecot’s Local Mail Transfer Protocol (LMTP) and the Sieve plugin, in the next tutorial: Raspberry Pi Email Server Part 5: Spam Sorting with LMTP & Sieve.

Let’s get started:

Installing & Configuring Spamassassin

First, install Spamassassin:

sudo apt-get update
sudo apt-get install spamassassin

Now we need to edit values in the file /etc/spamassassin/local.cf. Some of these may already be set, in which case you can leave them as they are; add or amend the others as necessary:

This one will add the spam score to the subject line of emails that Spamassassin considers to be spam:

rewrite_header Subject [***** SPAM _SCORE_ *****]

Spamassassin will also flag spam emails with “X-Spam-Flag: YES” in the headers. This flag is what we will eventually use to sort emails with; the rewritten subject line is purely to make the score easier to see.

This next setting will tell Spamassassin to modify headers only, without making any changes to the body of the email:

report_safe 0

This one lowers the threshold for mail to be considered spam from 5 to 2. You can change this later if you get lots of false positives, but it’s nice to have some emails set off the rules to begin with, just so you know it’s working:

required_score 2.0

This tells Spamassassin to use Bayesian filtering:

use_bayes 1

This turns on automatic learning:

bayes_auto_learn 1

Now edit /etc/default/spamassassin and set:

ENABLED=1

You can now start the spamassassin daemon:

sudo service spamassassin start

If you are using a modern Debian derivative (Jessie or later), the init system has changed to systemd. You need to run this additional command to enable spamassassin, which will cause it to automatically start when you boot:

sudo systemctl enable spamassassin

Instructing Postfix to use Spamassassin

At this stage, the Spamassassin daemon is running but none of your incoming emails are being passed through it. We need to edit this line in /etc/postfix/master.cf (just under the headers):

smtp      inet  n       -       -       -       -       smtpd
        -o content_filter=spamassassin

And append this to the bottom of that same file, which will pipe the output back to Postfix using the Postfix’s Sendmail compatibility interface:

spamassassin    unix  -       n       n       -       -       pipe user=debian-spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Note: this is all one line, even if it appears wrapped in your browser.

Now restart postfix:

sudo service postfix restart

If you get an error like this:

[....] Stopping Postfix Mail Transport Agent: postfix/usr/sbin/postconf: fatal: file /etc/postfix/master.cf: line 22: bad field count
postfix/postfix-script: fatal: cannot execute /usr/sbin/postconf!
 failed!

…then check the whitespace before the -o in content_filter=spamassassin. I can’t quite remember what I did but I think I changed tabs to spaces or the other way round, and then restarted postfix.

Now watch the mail log with this command:

tail -f /var/log/mail.log

…and send a test email. You should see testing something like this:

Jan  8 22:21:18 samhobbs postfix/smtpd[952]: connect from blu0-omc2-s3.blu0.hotmail.com[65.55.111.78]
Jan  8 22:21:19 samhobbs postfix/smtpd[952]: 542E83F519: client=blu0-omc2-s3.blu0.hotmail.com[65.55.111.78]
Jan  8 22:21:19 samhobbs postfix/cleanup[957]: 542E83F519: message-id=
Jan  8 22:21:19 samhobbs postfix/qmgr[941]: 542E83F519: from=, size=1579, nrcpt=1 (queue active)
Jan  8 22:21:19 samhobbs spamd[445]: spamd: connection from localhost [127.0.0.1] at port 35680
Jan  8 22:21:19 samhobbs postfix/smtpd[952]: disconnect from blu0-omc2-s3.blu0.hotmail.com[65.55.111.78]
Jan  8 22:21:19 samhobbs spamd[445]: spamd: setuid to debian-spamd succeeded
Jan  8 22:21:19 samhobbs spamd[445]: spamd: creating default_prefs: /var/lib/spamassassin/.spamassassin/user_prefs
Jan  8 22:21:19 samhobbs spamd[445]: config: created user preferences file: /var/lib/spamassassin/.spamassassin/user_prefs
Jan  8 22:21:19 samhobbs spamd[445]: spamd: processing message  for debian-spamd:111
Jan  8 22:21:24 samhobbs spamd[445]: spamd: clean message (0.0/2.0) for debian-spamd:111 in 5.0 seconds, 1541 bytes.
Jan  8 22:21:24 samhobbs spamd[445]: spamd: result: . 0 - HTML_MESSAGE,MSGID_FROM_MTA_HEADER scantime=5.0,size=1541,user=debian-spamd,uid=111,required_score=2.0,rhost=localhost,raddr=127.0.0.1,rport=35680,mid=,autolearn=ham
Jan  8 22:21:24 samhobbs postfix/pickup[940]: D83DE3F521: uid=111 from=
Jan  8 22:21:24 samhobbs postfix/pipe[958]: 542E83F519: to=, relay=spamassassin, delay=5.7, delays=0.44/0.05/0/5.2, dsn=2.0.0, status=sent (delivered via spamassassin service)
Jan  8 22:21:24 samhobbs postfix/qmgr[941]: 542E83F519: removed
Jan  8 22:21:24 samhobbs postfix/cleanup[957]: D83DE3F521: message-id=
Jan  8 22:21:24 samhobbs postfix/qmgr[941]: D83DE3F521: from=, size=1890, nrcpt=1 (queue active)
Jan  8 22:21:25 samhobbs postfix/local[964]: D83DE3F521: to=, relay=local, delay=0.2, delays=0.06/0.1/0/0.03, dsn=2.0.0, status=sent (delivered to maildir)
Jan  8 22:21:25 samhobbs postfix/qmgr[941]: D83DE3F521: removed
Jan  8 22:21:25 samhobbs spamd[439]: prefork: child states: II

So the steps you can see here are:

  1. Outlook server connects to RasPi/Postfix on port 25
  2. Postfix accepts the message and hands it to Spamassassin to process
  3. Spamassassin decides the message is clean and marks it as HAM
  4. The email is passed back from Spamassassin to Postfix and delivered to the inbox

Training Spamassassin

We’ve deliberately set the score limit for spam to a low value. This inevitably means we’ll get some false positives, but we can use these to train Spamassassin and make it better.

First, some things to understand about the Maildir format we’re using. Here’s what my structure looks like:

admin@samhobbs ~ $ sudo ls -al /home/sam/Maildir/
total 604
drwx------ 12 sam sam   4096 Mar  6 14:55 .
drwxr-xr-x  3 sam sam   4096 Mar  5 23:07 ..
drwx------  2 sam sam  36864 Mar  6 12:59 cur
-rw-------  1 sam sam  11920 Mar  6 04:14 dovecot.index
-rw-------  1 sam sam 415744 Mar  6 14:50 dovecot.index.cache
-rw-------  1 sam sam  10332 Mar  6 13:08 dovecot.index.log
-rw-------  1 sam sam  32784 Mar  5 16:22 dovecot.index.log.2
-rw-------  1 sam sam     30 Jan 13 22:30 dovecot-keywords
-rw-------  1 sam sam    144 Mar  3 17:49 dovecot.mailbox.log
-rw-------  1 sam sam  27138 Mar  6 09:27 dovecot-uidlist
-rw-------  1 sam sam      8 Mar  5 23:07 dovecot-uidvalidity
-r--r--r--  1 sam sam      0 Nov 23 22:55 dovecot-uidvalidity.52913278
drwx------  5 sam sam   4096 Mar  5 22:36 .Drafts
drwx------  5 sam sam   4096 Mar  4 21:53 .foo
drwx------  5 sam sam   4096 Mar  3 17:49 .INBOX.foo
drwx------  2 sam sam   4096 Mar  6 09:37 new
drwx------  5 sam sam   4096 Mar  5 22:36 .Sent
drwx------  5 sam sam   4096 Mar  6 14:37 .Spam
-rw-------  1 sam sam     37 Mar  3 17:49 subscriptions
drwx------  5 sam sam   4096 Nov 27 19:00 .Templates
drwx------  2 sam sam   4096 Mar  6 09:27 tmp
drwx------  5 sam sam   4096 Mar  6 04:08 .Trash

You can see I’ve created a couple of test folders here: one top level folder called “foo” and another subfolder in the inbox also called “foo” (.INBOX.foo). Each folder has three subdirectories: new for new (unread) emails, cur for emails that have been read, and tmp for temporary storage during delivery.

You can read more about this on the Dovecot Wiki if you’d like to know more.

So, the important thing to take away from this is that HAM emails are stored here:
/home/username/Maildir/cur

…and SPAM emails will be stored here (after sieve has been configured):
/home/username/Maildir/.Spam/cur

Spamassassin has a commandline training tool that is invoked like this:

sa-learn --no-sync [--spam or --ham] [folder/{cur,new}]

Each user has its own spamassassin database, which is located in the user's home directory in a hidden folder (.spamassassin). By default, the sa-learn command trains the database in the home directory of the user running the command, and since the spamassassin pipe we set up processes email as the user debian-spamd, we need to make sure we train the database in debian-spamd's home directory (which is /var/lib/spamassassin - you can check by looking in /etc/passwd). Unfortunately, if you run the command as debian-spamd using sudo -u debian-spamd command, you won't have read permissions for your emails.

Here’s the plan: move any false positives back into the inbox with your email client, and move any missed spam into the spam folder. Then run these three commands using sudo, so you have permission to read your emails and write to the spamassassin database, and use the --dbpath option to specify which database to write to:

# Scan HAM
sudo sa-learn --dbpath /var/lib/spamassassin/.spamassassin/ --no-sync --ham /home/username/Maildir/{cur,new}
# Scan SPAM
sudo sa-learn --dbpath /var/lib/spamassassin/.spamassassin/ --no-sync --spam /home/username/Maildir/.Spam/{cur,new}
# sync the journal and databases
sudo sa-learn --dbpath /var/lib/spamassassin/.spamassassin/ --sync

On my Pi, running the HAM command took about 5mins to process ~500 messages, with WordPress running at the same time. If you’re sure you will always move emails into the correct folders, you could add these two commands to a cron job so that they run regularly and keep everything up to date.

Alternatively, you can just run the commands when you notice a few false positives or missed spam emails. Over time, your spam filter will get better and better.

Automated learning using a script

If you don't want to run the commands manually all the time, you can use this simple cron job I wrote. The cron job runs as root, so you don't need the sudo part we used earlier. Create the script like this:

sudo nano /etc/cron.daily/spamassassin-learn

Now copy and paste this into the file (ctrl + shift + v to paste in nano):

#!/bin/bash

# Script by Sam Hobbs, see the following URL for updates:
# https://samhobbs.co.uk/2014/03/raspberry-pi-email-server-part-4-spam-detection-with-spamassassin

# redirect errors and output to logfile
exec 2>&1 >> /var/log/spamassassin.log

NOW=$(date +"%Y-%m-%d")

# Headers for log
echo ""
echo "#================================ $NOW ================================#"
echo ""

# learn HAM
echo "Learning HAM from Inbox"
sa-learn --dbpath /var/lib/spamassassin/.spamassassin/ --no-sync --ham /home/sam/Maildir/{cur,new}

# learn SPAM
echo "Learning SPAM from Spam folder"
sa-learn --dbpath /var/lib/spamassassin/.spamassassin/ --no-sync --spam /home/sam/Maildir/.Spam/{cur,new}

# Synchronize the journal and databases.
echo "Syncing"
sa-learn --dbpath /var/lib/spamassassin/.spamassassin/ --sync

Important: edit the paths so that they match your username! If you want to scan ham and spam for all users (this only works if you trust all users to be sensible and move ham/spam to the right folder) then replace the username "sam" with a glob ("*"), i.e:

sa-learn --dbpath /var/lib/spamassassin/.spamassassin/ --no-sync --ham /home/*/Maildir/{cur,new}

Now make the script executable:

sudo chmod +x /etc/cron.daily/spamassassin-learn

The script will learn from ham/spam daily, and write a log file at /var/log/spamassassin.log. Make sure you move any spam you find into your spam folder, and any false positives back into your inbox. Don't worry if ham is accidentally marked as spam one day and gets "learned", if you move the messages to their correct locations then the next time the script runs spamassassin will correct itself.

What’s next?

We’re now done with Spamassassin. The only thing left to do is find a way to sort spam emails directly into the spam folder, which is covered in the next tutorial: Raspberry Pi Email Server Part 5: Spam Sorting with LMTP & Sieve.

Feel free to leave a comment to let me know how you get on!

Type: 

Comments

Hi Sam
Since installing spamassassin I've stopped being able to receive emails. I get errors such as the following in mail.err
spamc[1505]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused
and eventually
spamc[1505]: connection attempt to spamd aborted after 3 retries

Could you give me any pointers to the issue?

Thanks

Mike

Hi Sam,
I'm preparing to install SpamAssassin (Tutorial 4) but need to correct a confusion. In the Introduction you write: "Spamassassin doesn’t actually sort the mail into the spam folder, it only changes information in the headers based on the results of the scan." However, in Tutorial 4 you also write at the end of the installation section:

So, the important thing to take away from this is that HAM emails are stored here:
/home/username/Maildir/cur

…and SPAM emails are stored here:
/home/username/Maildir/.Spam/cur

This suggests that SpamAssassin *does* sort spam mail into the spam folder. Which seems to contradict the opening statement that only headers are changed. I am misunderstanding something...

Please advise...John

Well spotted, I should have said "spam emails will be stored here (after sieve has been set up):".

I'll change it.

Sam

Sam, Thanks for the clarification. Will proceed to install and test (Tutorial 4 only for the moment)
John

Hi Sam,
Tutorial 4 implemented. Tested with special XJS*C4... line in the body of a message sent from an external mail service (not by telnet). I found in the received mail:
1. Headers did include the line: X-Spam-Flag: Yes
2. The subject line of the email was not rewritten with the score
3. The body of the email contained several lines starting with: Spam dectection software, running on the system "...pi2", etc
with an analysis of the detection, followed at the end by the delivered email in full, unchanged.

I expected to see the email exactly as sent but with only the subject line altered. Is this because the XJS*C4 line is a special trigger used by Apache2 and not SpamAssassin?

John

John,

I know there are options that control that behaviour, they might be defaults that have changed between Wheezy and Jessie.

Just to check - did you restart the spamassassin daemon before testing?

I'll have a look at my defaults tonight to compare.

Sam

Sam,

Yes, my test was the first attempt after installation and starting spamassassin.

I have just received a 'genuine' phishing email which the code picked up as bad, with a message:

"The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus"

Doing a hexdump of the attachment I find that it wants me to visit a URL which the code analysis reports as:
"0.0 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist
[URIs: appleton-community.com]"

Hmmm. The code works well.

In this case the nature of the message (purporting to come from Apple) made it obviously suspicious, even without SpamAssassin's help.

If you want a copy of the first test message as received with all headers, I can send it.

John

Hi Sam,

With regard to absent score in Subject header:

I looked at S-A Cconfiguration files and noticed that "rewrite_header Subject" (as per your Tutorial) is defined as "rewrite_header subject" in the definitions. So I changed my local.cf file to use lower case subject and repeated the XJS*C4 test and now I find:
1. The subject header is this: [***** SPAM 997.7 *****] Fwd: Special test
2: The email no longer contains the full analysis as it did previously but is exactly as sent (except for the addition in the Subject field).

I also see this in /etc/default/spamassassin:

# If you're using systemd (default for jessie), the ENABLED setting is
# not used. Instead, enable spamd by issuing:
# systemctl enable spamassassin.service
# Change to "1" to enable spamd on systems using sysvinit:
ENABLED=1

I am using Jessie. Perhaps it was correctly started later when I issued a "service spamassassin restart" at some point. Would you advise replacing "ENABLED=1" with "systemctl enable spamassassin.service" so that everything starts up properly after a reboot?

John

Ah, well researched. I'll check my config to see if I have upper or lower case Subject.

Yes, enable the spamassassin daemon using that command. Looks like I'll have to update this tutorial a bit more for Jessie.

Sam

Hi Sam,

I now receive daily reports:

/etc/cron.daily/spamassassin:
Synchronizing state for spamassassin.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d spamassassin defaults
Executing /usr/sbin/update-rc.d spamassassin enable

under this Subject heading: Cron <root@jmnpi2> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

There are four puzzles:

1. /etc/cron.daily/spamassassin has this code:

CRON=0

test -f /etc/default/spamassassin && . /etc/default/spamassassin

test -x /usr/bin/sa-update || exit 0
test -x /etc/init.d/spamassassin || exit 0

if [ "$CRON" = "0" ] ; then
exit 0
fi

but it appears that this if statement is not executed and the script continues. ???

Next is a subroutine which is probably called from a failure in the update section. This is why I get the email message.

# If there's a problem with the ruleset or configs, print the output
# of spamassassin --lint (which will typically get emailed to root)
# and abort.
die_with_lint() {
env -i LANG="$LANG" PATH="$PATH" start-stop-daemon \
--chuid debian-spamd:debian-spamd --start \
--exec /usr/bin/spamassassin -- -D --lint 2>&1
exit 1
}

This is probably called from the update section.
# got updates!
env -i LANG="$LANG" PATH="$PATH" start-stop-daemon \
--chuid debian-spamd:debian-spamd --start \
--exec /usr/bin/spamassassin -- --lint 2>&1 || die_with_lint
do_compile
reload

2. Jessie does not have sysvinit

3. I am not sure where run-parts --report /etc/cron.daily is launched

4. I have run (suggestion from https://wiki.apache.org/spamassassin/WritingRules)

spamassassin --lint and no errors are generated. However, when I run this (as in the script)
spamassassin -- --lint I get this output

jmnpi2:~> spamassassin -- --lint
Aug 8 12:03:38.842 [16448] warn: archive-iterator: no access to --lint: No such file or directory at /usr/share/perl5/Mail/SpamAssassin/ArchiveIterator.pm line 830.
Aug 8 12:03:38.844 [16448] warn: archive-iterator: unable to open --lint: No such file or directory

What is the meaning of the additional --?
Is there a problem with this cron script (not least, since it should not be running at all)?

Any advice? John

John,

Double dash in BASH means "end of arguments", so you've effectively called spamassassin on the file --lint, which doesn't exist (see here).

Systemd has a sysvinit compatibility mode, which may behave differently to "true" sysvinit. Not sure what to do about it, I'm still running ubuntu 14.04 on my server, which is due an upgrade to 16.04 imminently so I'll sort out all the differences on a systemd system when that's up and running. In the meantime, if you can figure it out then let me know!

Sam

Hi Sam,

"Double dash means end of arguments" so this line in /etc/cron.daily/spamassassin

--exec /usr/bin/spamassassin -- --lint 2

is completely nonsensical! No wonder it fails...

This script is in trouble since, with CRON=0, it should never be executed.

Time to remove it from /etc/cron.daily/ for the moment.

John

Hi Sam,
Thank you very much for your tutorial. We definitely need more people like you in this world. One issue. I have done the setup atleast two times, but after I set up spamassassin, I send a test email as instructed. Instead of the service marking it as spam, it instead completely rejects the email and relays it back to the sender. In the email sent back it says that Spamassassin rejected the email. Do you have any idea what is causing this instead of it just being marked? Thank you again.
Larry

Firstly, thanks for a great tutorial, this was really easy to follow.

One thing that's worth noting though, is that starting with jessie, you need to run:
sudo systemctl enable spamassassin
otherwise SpamAssassin won't auto-start on boot.

I have on my RPiv3 using raspbian jessie as a webserver and email server for quite some months without much issue.
Suddenly today I am getting "CleanMail.sh: not found" messages and I cannot discover why and how to stop these messages.
Please help.

Hopefully I fixed the previously mentioned error but now I get
spamc[2967]: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused

Sorry, I'm a bit in the dark about all this because I haven't seen this issue before, but is the spamassassin daemon running?

Sam

I'm trying to determine if it's a one-off issue, or a recurring problem - can you have a look through your mail log?

I think spamassassin limits the number of child processes to prevent denial of service attacks (so if you have loads of emails to be filtered then most of them wait in the postfix queue while 3 spamassassin processes sort spam). The odd rejection would be normal but consistent rejections are unusual. I'd have to check to make sure that's true, but I think it's what happens.

Sam

What I am getting in my mail.log is as follows
Nov 3 11:20:33 stockton postfix/smtpd[28673]: NOQUEUE: reject: RCPT from unknown[199.122.124.33]: 450 4.7.1 <mta.mail.woolworths.co.za>: Helo command rejected: Host not found; from=<bounce-600_HTML-122953769-1121562-7001459-5713@bounce.mail.woolworths.co.za> to=<ADRIAN@ADRIAN.CO.ZA> proto=ESMTP helo=<mta.mail.woolworths.co.za>
Nov 3 11:20:34 stockton postfix/smtpd[28673]: disconnect from unknown[199.122.124.33]

This is because the email server is helo'ing with a domain name that doesn't have a DNS A or MX record - if you look through the comments you'll find some discussion with other people about this.

Basically, I consider this to be a misconfiguration of Woolworths' mail server (blast from the past there, we don't have Woolies here any more) but I doubt you'll get them to change it.

Sam

Just to let you all know that found that spamassasin is not started on boot on rpi with ipv6 disabled and this is how I solved.

command: systemctl status spamassassin.service

show this error log:
Jan 10 15:17:14 rpi3 spamd[600]: server socket setup failed, retry 4: spamd: could not create IO::Socket::IP socket on [127.0.0.1]:783: Address already in use
Jan 10 15:17:15 rpi3 spamd[600]: server socket setup failed, retry 5: spamd: could not create IO::Socket::IP socket on [127.0.0.1]:783: Address already in use
Jan 10 15:17:16 rpi3 spamd[600]: server socket setup failed, retry 6: spamd: could not create IO::Socket::IP socket on [127.0.0.1]:783: Address already in use
Jan 10 15:17:17 rpi3 spamd[600]: server socket setup failed, retry 7: spamd: could not create IO::Socket::IP socket on [127.0.0.1]:783: Address already in use
Jan 10 15:17:18 rpi3 spamd[600]: server socket setup failed, retry 8: spamd: could not create IO::Socket::IP socket on [127.0.0.1]:783: Address already in use
Jan 10 15:17:19 rpi3 spamd[600]: server socket setup failed, retry 9: spamd: could not create IO::Socket::IP socket on [127.0.0.1]:783: Address already in use
Jan 10 15:17:20 rpi3 spamd[600]: spamd: could not create IO::Socket::IP socket on [127.0.0.1]:783: Address already in use
Jan 10 15:17:20 rpi3 systemd[1]: spamassassin.service: control process exited, code=exited status=98
Jan 10 15:17:20 rpi3 systemd[1]: Failed to start Perl-based spam filter using text analysis.
Jan 10 15:17:20 rpi3 systemd[1]: Unit spamassassin.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

problem is that by default spamd try to listen also on IPv6 and if is not available will fail to start on boot but will start ok if service is started manual.

the solution is to specify to listen only on ipv4 localhost / 127.0.0.1 adding this parameter --listen-ip=127.0.0.1 in:
/etc/default/spamassassin

OPTIONS=" --listen-ip=127.0.0.1 --create-prefs --max-children 5 --helper-home-dir"

after this all it is ok, spamassassin will start normal on boot.

Lucian
p.s.
Sam thank you again for you hard work with all tutorials.

This is a common thread, but I haven't found any definitive answers to why some email don't get scanned - no headers added. My RPi server was working perfectly for several months, but now is letting lots of spam through without any SA headers added at all - It's as if they aren't scanned at all. I know this is a SA issue, not specifically dealing with your tutorial, I am just reaching out in case you're familiar with the problem and know a fix or can point me in a better direction. All ham seems to get scanned, some spam above a certain score gets deleted, some spam gets scanned and detected and filed properly, but there are many spams that don't appear to get scanned at all. Any ideas? As I said the famous line - It used to work perfectly! :)

How long ago did you create the spamassassin training script? I realised quite recently that my script was training the wrong spamassassin database (the one for root instead of the one for debian-spamd). I changed the script to train the correct database using the --dbpath option, and added a bit of explanation (refer to the article for the rest):

Each user has its own spamassassin database, which is located in the user's home directory in a hidden folder (.spamassassin). By default, the sa-learn command trains the database in the home directory of the user running the command, and since the spamassassin pipe we set up processes email as the user debian-spamd, we need to make sure we train the database in debian-spamd's home directory (which is /var/lib/spamassassin - you can check by looking in /etc/passwd). Unfortunately, if you run the command as debian-spamd using sudo -u debian-spamd command, you won't have read permissions for your emails.

Here’s the plan: move any false positives back into the inbox with your email client, and move any missed spam into the spam folder. Then run these three commands using sudo, so you have permission to read your emails and write to the spamassassin database, and use the --dbpath option to specify which database to write to:

Sam

Messages over 250k are not being scanned and are bypassing spamassassin completely (no headers). There are copious threads about this, but none help me know where this limit can be set - Postfix? Dovecot? LMTP?

So my question now is, in the Postfix-Dovecot-Spamassassin email server, where can I set the max message size? There is an option to set max size with a spamc option, e.g. spamc -s 900000, but I don't see where to put that or can I run it once simply from the command line?

Any idea where to set the max size for sending to spamassassin? Thanks!

I just tried setting the spamc -s option for size in the last line of Postfix' master.cf. This last line was referenced in the tutorial, and I just added in the -s option. We'll see if that takes care of it.

Pages

Add new comment