Differences between revisions 15 and 32 (spanning 17 versions)
Revision 15 as of 2015-10-21 14:37:02
Size: 6402
Editor: ?LarsCebulla
Comment: add Jessie version
Revision 32 as of 2021-05-31 08:33:17
Size: 9004
Editor: PaulWise
Comment: cleanup: https, link updates, formatting, wording, space
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: English - [[it/DebianSpamAssassin|Italiano]] - [[ru/DebianSpamAssassin|Русский]] -~ ~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: English - [[it/DebianSpamAssassin|Italiano]] - [[pt_BR/DebianSpamAssassin|Português Brasileiro]] - [[ru/DebianSpamAssassin|Русский]] -~
Line 5: Line 5:

'''ToDo: This page needs to be brought up to date.'''
Line 6: Line 9:
!SpamAssassin is an extensible email filter which is used to identify spam. It has a wide range of features, uses DNSBL tests, heuristics, bayesian classification and other concepts to tell your spam from ham.
Line 8: Line 10:
The official !SpamAssassin homepage is at [[http://spamassassin.apache.org/]] !SpamAssassin is an extensible email filter which is used to identify spam. It has a wide range of features, uses DNSBL tests, heuristics, Bayesian classification and other concepts to tell your spam from ham.
Line 10: Line 12:
== Versions of Debian Packages == The official !SpamAssassin homepage is at [[https://spamassassin.apache.org/]]
Line 12: Line 14:
## * [[DebianEtch|Etch]] has [[DebianPkg:etch/spamassassin|3.1.7]].
## * [[DebianLenny|Lenny]] has [[DebianPkg:lenny/spamassassin|3.2.5]], which is the latest official release.
 * [[DebianSqueeze|Squeeze]] has [[DebianPkg:squeeze/spamassassin|3.3.1]]
 * [[DebianWheezy|Wheezy]] has [[DebianPkg:wheezy/spamassassin|3.3.2]]
 * [[DebianJessie|Jessie]] has [[DebianPkg:jessie/spamassassin|3.4.0]]
After having set up !SpamAssassin one can easily test if it is indeed working properly by using GTUBE (Generic Test for Unsolicited Bulk Email) (!SpamAssassin wiki page on this: [[https://spamassassin.apache.org/gtube/]]).
The premise of this is simple; send an email with the GTUBE string as its body to your mail server from an external mail address and !SpamAssassin should automatically mark it as spam. The 68-byte GTUBE string used for this is as follows: {{{XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X}}}

= Packages in Debian =

The Debian distribution contains the following main !SpamAssassin packages:

 * DebianPkg:spamassassin - Perl-based spam filter using text analysis
 * DebianPkg:spamc - Client for !SpamAssassin spam filtering daemon
Line 20: Line 26:
= Setup Postfix with SA 3.3.2 (Wheezy) =
This tutorial will show you how to integrate SA into postfix to scan your emails for spam. It is assumed that postfix is installed and configured properly. You will need those packages (and resulting dependencies):
 *
postfix
 * spamassassin
 * spamc
= Setup Postfix with SA 3.4.2 (Buster) as a Content Filter =

This tutorial will show you how to integrate SA into postfix to scan your emails for spam. It is assumed that postfix is installed and configured properly. You will need these packages (and resulting dependencies): DebianPkg:postfix DebianPkg:spamassassin DebianPkg:spamc
Line 27: Line 31:
Line 30: Line 35:
Add to your smtp and submission service
Add to your smtp/smtps and submission service:
Line 32: Line 39:
-o content_filter=spamassassin   -o content_filter=spamassassin
Line 35: Line 42:
which will result at least in which will result at least in:
Line 39: Line 46:
  -o content_filter=spamassassin   -o content_filter=spamassassin
Line 41: Line 48:
  -o content_filter=spamassassin   -o content_filter=spamassassin
Line 46: Line 53:
We have to add the spamassassin service by adding We have to add the spamassassin service by adding:
Line 51: Line 59:
Line 53: Line 62:
=== main.cf ===
No changes necessary.
=== Final steps ===
Line 56: Line 64:
=== Final steps ===
Reload postfix configuration by
{{{
postfix reload
}}}
or
{{{
service postfix reload
}}}
Reload postfix configuration by running either "{{{postfix reload}}}" or "{{{service postfix reload}}}" as root.
Line 67: Line 67:
In the SA config files you can make changes according to your flavor. E.g. in
{{{
/etc/spamassassin/local.cf
}}}
you can uncomment the line

In the SA config files you can make changes according to your preference. E.g. in "{{{/etc/spamassassin/local.cf}}}" you can uncomment the line
Line 75: Line 73:
Line 77: Line 76:
Another mechanism with which to mark spam in your MUA is to filter for the flag "{{{X-Spam-Flag: YES}}}" in incoming mail's headers ({{{spamd}}} automatically appends this flag to the headers of spam mails — assuming you are using the default configuration).

= Setup Postfix with SA 3.4.2 (Buster) as a Milter =

Another way of running SA with Postfix is as a Milter. Should have a section on the merits of the two approaches.

== Postfix ==

The daemon '''spamass-milter''' will be called by the postfix 'smtp' (and submission) binary. It runs the '''spamc''' binary which passes the email to '''spamd''' (daemonized SA) and uses the Milter protocol to send header changes as required.

This tutorial will show you how to integrate SA into postfix to scan your emails for spam. It is assumed that postfix is installed and configured properly. You will need these packages (and resulting dependencies): DebianPkg:postfix DebianPkg:spamassassin DebianPkg:spamass-milter DebianPkg:spamc

=== master.cf ===

No changes necessary.

=== main.cf ===

Change your main.cf to have something like the following for the smtpd_milters (you can have other milters too with commas separating multiple milters).

{{{
smtpd_milters = unix:/var/spool/postfix/spamass/spamass.sock
}}}

Please note that if Postfix is running in a chroot (which it is by default) your path will be different:

{{{
smtpd_milters = unix:/spamass/spamass.sock
}}}

=== /etc/default/spamass-milter ===

The following line is probably the only one you need to change in this file. The '''-r''' parameter specifies the Spam score for rejecting mail (which should be the same as used in SA config) and the '''-s''' parameter (which applies to spamc as it's after '''--''') specifies the maximum message size to scan (the default of 500K is too small for most modern systems).

{{{
OPTIONS="-u spamass-milter -i 127.0.0.1 -r 5 -- -s 10485760"
}}}

Then just setup the rest of SA as normal.
Line 78: Line 117:
Line 82: Line 122:
First of all, you need the DebianPkg:exim4-daemon-heavy which has exiscan-acl. The latter allows scanning messages. Then, you need SA installed, and just follow the documentation [[http://duncanthrax.net/exiscan-acl/|exiscan-acl-docs]]. First of all, you need the DebianPkg:exim4-daemon-heavy which has exiscan-acl. The latter allows scanning messages. Then, you need SA installed, and just follow the documentation [[https://duncanthrax.net/exiscan-acl/|exiscan-acl-docs]].
Line 85: Line 125:
In the file /etc/exim4/conf.d/main/15_spamassassin-config I have simply the following:{{{
   

In the file /etc/exim4/conf.d/main/15_spamassassin-config I have simply the following:

{{{
Line 91: Line 133:
Line 100: Line 143:
Line 105: Line 149:
Line 107: Line 152:
        spam = nobody:true         spam = debian-spamd:true
Line 109: Line 154:
Line 111: Line 157:
        spam = nobody         spam = debian-spamd
Line 113: Line 159:
        spam = nobody         spam = debian-spamd
Line 115: Line 161:
 {{{
{{{
Line 118: Line 165:
         spam = nobody:true          spam = debian-spamd:true
Line 125: Line 172:
Line 129: Line 177:
The other thing are relays. Spammers often take over relays to obscure the true source of the spams. If a relay under a spammer's control generate a bounce message based on your rejection, that bounce may go to an innocent thrid-party, which would be bad. That's the main reason why some consider this approach harmful. The other thing are relays. Spammers often take over relays to obscure the true source of the spams. If a relay under a spammer's control generate a bounce message based on your rejection, that bounce may go to an innocent third-party, which would be bad. That's the main reason why some consider this approach harmful.
Line 131: Line 179:
The advocates of this approach points out that spammers have no interest in generating bounces, as that would only cut into their own spamming bandwidth and make them less efficient. Therefore, one rarely sees a raped relay, or a spammer himself, generate a bounce, which solves the problem. The advocates of this approach points out that spammers have no interest in generating bounces, as that would only cut into their own spamming bandwidth and make them less efficient. Therefore, one rarely sees a hijacked relay, or a spammer himself, generate a bounce, which solves the problem.
Line 133: Line 181:
Other advocates hold the position that "my system, my responsibility, your system, your responsiblity", implying that an administrator would need a heads-up he would get from letting his relay pass on spam. Other advocates hold the position that "my system, my responsibility, your system, your responsibility", implying that an administrator would need a heads-up he would get from letting his relay pass on spam.
Line 137: Line 185:
 * http://spamassassin.apache.org/ - Project homepage;
  * http://wiki.apache.org/spamassassin/ - Wiki;
   * http://wiki.apache.org/spamassassin/FrequentlyAskedQuestions - Frequently Asked Questions
 * [[https://spamassassin.apache.org/|Project homepage]]
 * [[https://cwiki.apache.org/confluence/display/spamassassin/|Wiki]]
 * [[https://cwiki.apache.org/confluence/display/spamassassin/FrequentlyAskedQuestions|Frequently Asked Questions]]
Line 142: Line 190:
FixMe: This page needs to be brought up to date. CategoryNetwork CategorySoftware CategoryMail CategoryAntiSpam

Translation(s): English - Italiano - Português Brasileiro - Русский


ToDo: This page needs to be brought up to date.

SpamAssassin

SpamAssassin is an extensible email filter which is used to identify spam. It has a wide range of features, uses DNSBL tests, heuristics, Bayesian classification and other concepts to tell your spam from ham.

The official SpamAssassin homepage is at https://spamassassin.apache.org/

After having set up SpamAssassin one can easily test if it is indeed working properly by using GTUBE (Generic Test for Unsolicited Bulk Email) (SpamAssassin wiki page on this: https://spamassassin.apache.org/gtube/). The premise of this is simple; send an email with the GTUBE string as its body to your mail server from an external mail address and SpamAssassin should automatically mark it as spam. The 68-byte GTUBE string used for this is as follows: XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

Packages in Debian

The Debian distribution contains the following main SpamAssassin packages:

  • spamassassin - Perl-based spam filter using text analysis

  • spamc - Client for SpamAssassin spam filtering daemon

As SpamAssassin is a targetting a moving target, it is wise to keep it quite up-to-date, as spammers adapt to the filters to get their spew through.

Setup Postfix with SA 3.4.2 (Buster) as a Content Filter

This tutorial will show you how to integrate SA into postfix to scan your emails for spam. It is assumed that postfix is installed and configured properly. You will need these packages (and resulting dependencies): postfix spamassassin spamc

Postfix

SA will be used as a content filter for the postfix 'smtp' (and submission) binary. The spamc binary passes the email to spamd (daemonized SA) and then back to the mail queue.

master.cf

Add to your smtp/smtps and submission service:

  -o content_filter=spamassassin

which will result at least in:

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

or similiar.

We have to add the spamassassin service by adding:

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

at the end of the configuration file.

Final steps

Reload postfix configuration by running either "postfix reload" or "service postfix reload" as root.

Spamassassin

In the SA config files you can make changes according to your preference. E.g. in "/etc/spamassassin/local.cf" you can uncomment the line

rewrite_header Subject *****SPAM*****

to mark spam in your MUA in the message header.

Another mechanism with which to mark spam in your MUA is to filter for the flag "X-Spam-Flag: YES" in incoming mail's headers (spamd automatically appends this flag to the headers of spam mails — assuming you are using the default configuration).

Setup Postfix with SA 3.4.2 (Buster) as a Milter

Another way of running SA with Postfix is as a Milter. Should have a section on the merits of the two approaches.

Postfix

The daemon spamass-milter will be called by the postfix 'smtp' (and submission) binary. It runs the spamc binary which passes the email to spamd (daemonized SA) and uses the Milter protocol to send header changes as required.

This tutorial will show you how to integrate SA into postfix to scan your emails for spam. It is assumed that postfix is installed and configured properly. You will need these packages (and resulting dependencies): postfix spamassassin spamass-milter spamc

master.cf

No changes necessary.

main.cf

Change your main.cf to have something like the following for the smtpd_milters (you can have other milters too with commas separating multiple milters).

smtpd_milters = unix:/var/spool/postfix/spamass/spamass.sock

Please note that if Postfix is running in a chroot (which it is by default) your path will be different:

smtpd_milters = unix:/spamass/spamass.sock

/etc/default/spamass-milter

The following line is probably the only one you need to change in this file. The -r parameter specifies the Spam score for rejecting mail (which should be the same as used in SA config) and the -s parameter (which applies to spamc as it's after --) specifies the maximum message size to scan (the default of 500K is too small for most modern systems).

OPTIONS="-u spamass-milter -i 127.0.0.1 -r 5 -- -s 10485760"

Then just setup the rest of SA as normal.

Setting up Exim 4 and SA 2.64 to reject spam at SMTP time

<!> This section contains outdated information.

It is fairly easy to set up Exim4 and SA to reject spam in the SMTP dialogue, that is, while the spam is still in transmission and your system is still talking to the spammer.

First of all, you need the exim4-daemon-heavy which has exiscan-acl. The latter allows scanning messages. Then, you need SA installed, and just follow the documentation exiscan-acl-docs.

Details

In the file /etc/exim4/conf.d/main/15_spamassassin-config I have simply the following:

  spamd_address = 127.0.0.1 783

To avoid scanning messages that are destined to postmaster or abuse (and is their damned duty to read) modify the entry in /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt to read:

  accept local_parts = postmaster:abuse
         domains = +local_domains
         set acl_m0 = rfcnames

Then, the rest goes in /etc/exim4/conf.d/acl/40_exim4-config_check_data

Pretty high up, you need:

  accept condition = ${if eq{$acl_m0}{rfcnames} {1}{0}}

And then somewhere far down there:

  warn  message = X-Spam-Score: $spam_score ($spam_bar)
        spam = debian-spamd:true

  warn  message = X-Spam-Flag: YES
        spam = debian-spamd
  warn  message = X-Spam-Report: $spam_report
        spam = debian-spamd

  # reject spam at high scores (> 12)
  deny   message = This message scored $spam_score spam points.
         spam = debian-spamd:true
         condition = ${if >{$spam_score_int}{120}{1}{0}}

However, note that any errors can result in loss of valid e-mail, so make sure you have read and understand the official documentation before you use it. This is meant to give a taste of what is involved in getting it working.

Important Notes

It is controversial whether rejecting at SMTP time is such a good idea. The problem is, spammers (and viruses) routinely forge the from address on the envelope. This means that if there is a bounce generated, it will go to this address, which can be randomly generated, or worse, an innocent third party.

Therefore, it is very important that your system doesn't generate a bounce. That's your responsibility. For one thing, you can't accept a message and then bounce it, that would be wrong. You can't, for example, have your secondary MX accept a message and then have your primary reject it. If you are to use this, your primary and secondary MX should have identical configurations with respect to rejecting spam.

The other thing are relays. Spammers often take over relays to obscure the true source of the spams. If a relay under a spammer's control generate a bounce message based on your rejection, that bounce may go to an innocent third-party, which would be bad. That's the main reason why some consider this approach harmful.

The advocates of this approach points out that spammers have no interest in generating bounces, as that would only cut into their own spamming bandwidth and make them less efficient. Therefore, one rarely sees a hijacked relay, or a spammer himself, generate a bounce, which solves the problem.

Other advocates hold the position that "my system, my responsibility, your system, your responsibility", implying that an administrator would need a heads-up he would get from letting his relay pass on spam.

External Links


CategoryNetwork CategorySoftware CategoryMail CategoryAntiSpam