spasm v1.0 documentation

# Filter Documentation

Each filter has one of four settings: Off, Tag, Quarantine, and Reject. Because a message may be caught by multiple filters, the filter with the "highest" setting determines the action taken by spasm:

- If set to "Off", the filter is not checked.
- If set to "Tag", the message is stored for the current recipient, "X-spasm" headers are added to notify the user of the filter[s] which caught the message, and the entire message is remailed directly to the user. The stored message file is then deleted. A log entry gets appended to the user's spasm log.
- If set to "Quarantine", the message is stored for the current recipient, and "X-spasm" headers are added to notify the user of the filter[s] which caught the message. A log entry gets appended to the user's spasm log.
- If set to "Reject", the message is immediately rejected. A log entry gets appended to the user's spasm log.

There are two user options available, which control tagging and logging:

- USE_LOGGING: This configures which messages are logged. If set to "Off", nothing is logged. If set to "Tag", all messages at level 'Tag' and higher are logged (ie, everything is logged). If set to "Quarantine", all messages at level 'Quarantine' and higher are logged (ie, everything except 'Tag' messages). If set to "Reject", only messages at level 'Reject' are logged.
- USE_DOMAIN_LOGGING: If this is set, the address will use the domain's quarantine and rejection log. If not, it will use its own quarantine and rejection log. Can be helpful for virtual domain administrators to keep things in one place.
- USE_SUBJECT_TAGGING: Because some mail clients (notably, Outlook Express) do not allow custom filtering, turning this on will tag the subject line of the message with "**** X-spasm ****" for any tagged messages, instead of just adding header tags. This way, those mail clients can filter based on the subject line.

Following are the default filters included in spasm. In each filter, "reject" may mean any of the above three cases wherein the filter has been turned on (Tag, Quarantine, or Reject).

- SF_VIRUS_SCAN: This runs the message through a virus scanner if virus checking capabilities have been turned on by the Systems Administrator or ISP.
- SF_WHITELIST_ONLY: This will reject all messages. The purpose of this filter is to only allow email addresses or mail servers which have been explicitly listed in the user's whitelist. The user's whitelist is checked prior to any filter checks, so any message caught by the whitelist will automatically bypass all filters.
- SF_PERSONAL_BLACKLIST: This turns on the user's personal blacklist.
- SF_SPAMTRAP: This filter checks the message against the system's spamtrap blacklist. Mail servers are automatically added to this blacklist by spasm if they have attempted to send email to a "spamtrap" email address: that is, an email address which has been set up by the Systems Administrator specifically to catch spammers. Such an email address is not advertised openly, and should never receive email. Any email sent to such an address, therefore, is assumed to be spam.
- SF_MAX_UNKNOWN_USERS: Spasm will verify each recipient email address during an SMTP session, if the Systems Administrator has told it to do so, and will blacklist the sending server if too many unknown users are specified as recipients. If a user turns on this filter, this blacklist of servers who've tried to send to too many unknown users will be used. This is a good way of preventing dictionary attacks.
- SF_LOCALFILTER: This is nearly identical to SF_PERSONAL_BLACKLIST, except it is system-wide and is maintained by the Systems Administrator. This filter also checks the ENVFROM_DB, a more powerful system-wide list which is maintained by the Systems Administrator and offers more options in the way of blacklisting sender email addresses.
- SF_RDNS: This is a very aggressive filter, and will often catch legitimate email. This filter checks the IP address of the server trying to send a message. If the IP address does not resolve to a hostname (ie, it does not have a proper DNS entry), it is rejected. A large percentage of spammers use IP addresses that have no DNS entry, but likewise, there are many legitimate mail servers whose Systems Administrators have not set up proper DNS, so use this with caution.
- SF_HELO: This is a moderately aggressive filter, and may catch legitimate email. When one mail server connects to another, it should (but is not always required to) send what is called a "HELO/EHLO" command. This command allows the first mail server to identify itself to the second mail server, by sending its hostname. This filter checks the hostname given during the HELO/EHLO command against the server's actual hostname (by looking up its IP address). If they do not share at least the second-level domain portion, it is rejected (ie, with the hostname "my.mail.domain.com", it only checks the "domain.com" portion). This filter will stop a considerable amount of forged spam. If no HELO/EHLO command is given, this filter will also reject the message.
- SF_MAIL_HOST: This is a very aggressive filter, and will often catch legitimate email. This checks the second-level domain portion of the sender's email address against the second-level domain portion of the sending server's hostname. If they do not match, the message is rejected. This filter will stop messages which have been relayed through other servers. However, this means it will also stop messages that are legitimately being relayed (eg, virtual domain email).
- SF_SPAMASSASSIN: This runs SpamAssassin, a content filter, against the message.
- SA_REQUIRED_HITS: When SpamAssassin scans a message, it returns a numeric score based on its own scoring system. The value of SA_REQUIRED_HITS is checked against the score, and if the score is greater than or equal to the value set here, the message is rejected. A good moderate value is 5.
- SF_ORDB: This checks the sending server's IP address against the ORDB database. For more information, see http://www.ordb.org
- SF_DSBL: This checks the sending server's IP address against the DSBL database. For more information, see http://www.dsbl.org
- SF_SPAMCOP: This checks the sending server's IP address against the SpamCop database. For more information, see http://www.spamcop.net
- SF_SBL: This checks the sending server's IP address against the Spamhaus database. For more information, see http://www.spamhaus.org
- SF_SORBS: This checks the sending server's IP address against the SORBS database. For more information, see http://www.sorbs.net
- SF_POSTMASTERRFC:
- SF_DSNRFC:
- SF_ABUSERFC:
- WHOISRFC:
- IPWHOISRFC: The RFC filters check the sending server's IP address or hostname against the rfc-ignorant.org databases. For more information on any of these five filters, see http://www.rfc-ignorant.org
- SF_KOREABLACKHOLES:
- SF_CHINABLACKHOLES:
- SF_BRAZILBLACKHOLES:
- SF_JAPANBLACKHOLES:
- SF_TAIWANBLACKHOLES:
- SF_VERIOBLACKHOLES:
- SF_VALUEWEBBLACKHOLES:
- SF_RACKSPACEBLACKHOLES:
- SF_INFLOWBLACKHOLES:
- SF_BROADWINGBLACKHOLES:
- SF_XOBLACKHOLES:
- SF_ELIBLACKHOLES:
- SF_ARGENTINABLACKHOLES:
- SF_NIGERIABLACKHOLES:
- SF_RUSSIABLACKHOLES:
- SF_SINGAPOREBLACKHOLES:
- SF_THAILANDBLACKHOLES:
- SF_CIBERLYNXBLACKHOLES:
- SF_CWBLACKHOLES:
- SF_EPOCHBLACKHOLES:
- SF_HEBLACKHOLES:
- SF_INTERNAPBLACKHOLES:
- SF_LEVEL3BLACKHOLES:
- SF_RRBLACKHOLES:
- SF_SKYNETWEBBLACKHOLES:
- SF_WANADOOFRBLACKHOLES: The BLACKHOLES filters check the sending server's IP address against the blackholes.us databases. These databases do not imply that the server has ever sent spam or is prone to abuse. These databases simply describe networks that belong to each respective descriptor (eg, "SF_KOREABLACKHOLES" is a list of Korea's IP address space, "SF_LEVEL3BLACKHOLES" is a list of Level3's IP address space. For more information, see http://www.blackholes.us