SpamAssassin-usage.txt Guest on 26th June 2020 08:12:06 PM
  2. If you're receiving "spam", or more specifically "Unsolicited Bulk
  3. E-Mail (UBE)", CS has implemented a strategy to carefully handle the
  4. annoyance.
  6.       Introduction
  8. The software, SpamAssassin <http://spamassassin.org>, filters UBE
  9. by using:
  11.     * header analysis: spammers use a number of tricks to mask their
  12.       identities, fool you into thinking they've sent a valid mail, or
  13.       fool you into thinking you must have subscribed at some stage.
  14.       SpamAssassin tries to spot these.
  15.     * text analysis: again, spam mails often have a characteristic
  16.       style (to put it politely), and some characteristic disclaimers
  17.       and CYA text. SpamAssassin can spot these, too.
  18.     * Bayes classifier: this is a Bayesian-like form of
  19.       probability-analysis classification, using an algorithm based
  20.       on the one detailed in Paul Graham's "A Plan For Spam" paper at:
  21.          http://www.paulgraham.com/
  22.       It also incorporates some other aspects taken from Graham
  23.           Robinson's webpage on the subject at:
  24.              http://radio.weblogs.com/0101454/stories/2002/09/16/spamDetection.html
  25.     * DCC: DCC (Distributed Checksum Clearinghouse) is a system used to check
  26.       message signatures against a collaborative filtering network.
  28. Once identified, the mail can then be optionally tagged as spam for
  29. later filtering using the user's own mail user-agent application.
  31. Implementation
  33. It is recommended that this software isn't used to automatically delete
  34. any mail.
  35. There could be instances, however remote, where a legitimate message
  36. could be considered "spam", and if the SpamAssassin filter is configured
  37. to automatically delete "spam", you may be deleting important messages!
  38. In CS, we've implemented a mail filter stategy such that:
  40.     * filtering is easy for users to configure
  41.     * filtering is not mandatory -- we have no site-wide spam filtering.
  42.     * filtration of mail doesn't break any other CS policy
  44. Configuration
  46. If you haven't yet already created a .procmailrc file in your home
  47. directory, you should do so now with the following contents.(please also
  48. refer to How can I filter my mail in CS? </faqs/999716989> for more info
  49. about procmail.)
  50. The first "recipe" of this file should be (starting from the top of the
  51. file):
  53. :0fw
  54. | /its/software/bin/spamc -d spam.cs.caltech.edu
  55. :0:
  56. * ^X-Spam-Status: Yes
  57. Maildir/spam/
  59. which will instruct procmail to pipe (fw) all mail to the SpamAssassin
  60. server instead of merely invoking the application when mail arrives.
  61. When invoking spamassassin in this manner, spamassassin will
  62. pipe each mail back to procmail after the filter process is complete.
  63. When spamassassin has completed processing the mail, a header of
  64. X-Spam-Status: will be written into the mail.
  65. The next portion of the procmail "recipe" states that all mail which
  66. contains this X-Spam-Status: header is to be written to the folder
  67. "spam", in the Maildir directory.
  68. *NOTE: If you're an IMAP user, you'll want to name this folder .spam/
  69. (preceded with a "dot") to make this folder available in your IMAP
  70. client software.*
  71. *NOTE: Make sure to suffix all directory names with "/" (forward slash)
  72. to keep consistent with Maildir format. Procmail will consider any file
  73. or directory which ends with a forward slash to be in the Maildir format
  74. (without a slash will be considered a mbox-style file).*
  76. Finally, make sure that the last "recipe" in this file (at the very
  77. bottom of the file) consists of:
  79. :0
  80. *
  81. Maildir/
  83. as a "catch-all" for any messages which aren't tagged as "spam".
  84. If you haven't already, change your .forward file to contain:
  86. "| /usr/bin/procmail"
  88. The first time spamassassin runs, a .spamassassin directory will be
  89. created in your home directory. .spamassassin will contain
  90. auto-whitelist, user_prefs, and a few files whose name begins with "bayes_".
  91. auto-whitelist will contain addresses of senders in which you have
  92. received non-spam ("ham") mail from. This information is stored in
  93. binary format (not human-readable) and serves to decrease the odds of tagging a
  94. message from legitimate correspondance as "spam".
  95. user_prefs initially will be empty.
  96. By default, SpamAssassin is well suited to filter "spam", however,
  97. you may edit this file to suit SpamAssassin to your preferences.
  98. Please see Customization section <#custom> below for more information
  99. about customizing SpamAssassin.
  101. Operation
  103. If you've configured your .procmailrc file to save "spam" to a folder
  104. (wise choice), each spam message will contain a "score" and a report
  105. concerning why/how the message was considered to be "spam".
  106. An example:
  108. Subject: *****SPAM***** we are happy to help you find exactly what you are looking for
  112. Customization
  114. It is possible to customize SpamAssassin for your mail (or SPAM,
  115. depending on your point of view).
  116. Any customizations you make will be in ~/.spamassassin/user_prefs.
  118. SpamAssassin assesses a score to each message, and any message scored
  119. above the threshold (default is score of 5) is tagged as spam.
  120. The threshold may be changed in your .spamassassin/user_prefs file so
  121. that the file contains:
  123. required_hits 3.3
  125. to make the new threshold "3.3", which would cause more messages to be
  126. tagged as spam.
  128. Also, you may "black list" (10 points) addresses by specifying in your
  129. .spamassassin/user_prefs file:
  131.         blacklist_from [email protected]
  133. but of course you'd supply a different address than above.
  134. This setting also supports "globbing" of wildcards (regular expressions
  135. are not used for security reasons), such as:
  137. blacklist_from *@spamcenter.com
  139. The opposite of black listing, of course, is white listing, which causes
  140. mail from specific addresses to NOT be considered spam.
  141. This is useful if you receive legitimate correspondance, but
  142. SpamAssassin tags the message(s) as spam, for whatever reason.
  144. You may add a whitelist entry as:
  146. whitelist_from [email protected]
  148. To handle messages from mailing lists, you can use whitelist_from_rcvd
  149. in your ~/.spamassassin/user_prefs file such as:
  151. whitelist_from_rcvd lists.sourceforge.net sourceforge.net
  153. Use this to supplement the whitelist_from addresses with a check against
  154. the received headers. The first parameter is the address to whitelist,
  155. and the second is a domain to match in the received headers.
  156. For example,
  158. whitelist_from_rcvd [email protected] example.com
  159. whitelist_from_rcvd axkit.org sergeant.org
  161. You may also change the score given to a test. Scores can be positive or
  162. negative real numbers or integers. "SYMBOLIC_TEST_NAME" is the symbolic
  163. name used by SpamAssassin as a handle for that test;
  164. for example, 'FROM_ENDS_IN_NUMS'.
  166. score SYMBOLIC_TEST_NAME n.nn
  168. A list of tests (and default scores) can be found at
  169. http://spamassassin.org/tests.html.
  170. For more information about customization, please refer to the
  171. "Mail::SpamAssassin::Conf" man page, or
  172. man Mail::SpamAssassin::Conf at a command-line nearest yo

Paste is for source code and general debugging text.

Login or Register to edit, delete and keep track of your pastes and more.

Raw Paste

Login or Register to edit or fork this paste. It's free.