Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2004-11-11 13:41:52
Size: 1243
Editor: anonymous
Comment:
Revision 3 as of 2004-11-11 14:12:54
Size: 3074
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 14: Line 14:
== Setting up Exim 4 and SA 2.64 to reject spam at SMTP time ==
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 [http://duncanthrax.net/exiscan-acl/ exiscan-acl-docs].


=== 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 thrid-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 raped relay, or a spammer himself, generate a bounce, which solves the problem.

Information about SpamAssassin in Debian

?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 [http://spamassassin.apache.org/]

Versions of Debian Packages

  • Woody has 2.20, which is so outdated it is unusable.
  • Sarge has 2.64.
  • Sid has 3.0.0, which is the latest official release.

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.

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

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 [http://duncanthrax.net/exiscan-acl/ exiscan-acl-docs].

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 thrid-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 raped relay, or a spammer himself, generate a bounce, which solves the problem.

What's up with SpamAssassin 3.0.0?

?SpamAssassin 3.0.0 was released on 2004-09-22, and was uploaded to Sid a few days later.

Unfortunately, some Debian developers report huge memory consumption: [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275232 Bug275232], which is one of the things preventing it from entering testing. The ?SpamAssassin Developers are onto something [["SABug3776"] http://bugzilla.spamassassin.org/show_bug.cgi?id=3776], though, but the question remains if the issue can be resolved in time for Sarge's release.