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:
- Outlook server connects to RasPi/Postfix on port 25
- Postfix accepts the message and hands it to Spamassassin to process
- Spamassassin decides the message is clean and marks it as HAM
- 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!
Comments
Stopped receiving emails after installing spamassassin
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
SpamAssassin
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
SpamAssassin
Sam, Thanks for the clarification. Will proceed to install and test (Tutorial 4 only for the moment)
John
Spamassassin
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
new default parameters in jessie?
SpamAssassin
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
SpamAssassin
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
yes, enable the daemon
SpamAssassin Cron
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
double dash means "end of arguments"
--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! SamSpamassassin
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
After setting up Spamassassin..
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
SpamAssassin autostart on jessie
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.
CleanMail.sh not found
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.
I've never seen that error before
spamc cannot get to spamd
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
is spamassassin running?
Is spamassassin running?
ps aux | grep spam* tells me spamd is up and running
I'm trying to determine if it
I'm trying to determine if it's a one-off issue
I am still checking but I suspect that this is a one-off because of something or other that happened on my server. Just have to find what that is and it should be fixed.
I'm trying to determine if it's a one-off issue
Added the following to my /etc/network/interfaces and now I get mail
nameserver 8.8.8.8 192.168.0.1
dns-namservers 8.8.8.8
Why did the nameserver settings get lost in the 1st place?
I'm trying to determine if it's a one-off issue
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.c…> 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]
Mail server helo'ing with domain name that doesn't have DNS A/MX
spamassassin set-up correct but will not start on boot
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.
SA skipping some emails
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! :)
--dbpath option when training spamassassin
--dbpath
option, and added a bit of explanation (refer to the article for the rest): SamMessage size in the problem
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!
Postfix argument to spamc
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.
Thanks for looking into it
Add new comment