Feature Requests

[John Rudd]

1) new action type: Ham Actions or Not Spam Actions

    Similar to "Spam Actions" and "High Spam Actions", what to do if the
message isn't spam.  It may seem like you'd always want to "deliver",
but maybe not.  For one, you might want to strip-html even for ham.
For two, some of the new actions I'm going to propose might fit.


2) perhaps also a "Low Ham Actions" or "Low Not Spam Actions" and "Low
Ham Score"/"Low Not Spam Score"

   If the message's spam assassin score is lower than "Low Ham Score",
then use these actions instead of the Ham Actions.


3) "Actions Log File" and action "log"

    If you specify an action of log, then then 5 things will be put into
the log file (or log facility? perhaps something like
(FILE|SYSLOG):(PATH|FACILITY) ) you specify:

     a) From: sender
     b) "Mail From" sender and $_ (the qf relay)
     c) Recipient list
     d) Subject
     e) the DNSBLs and Spam Assassin score (like of the SpamCheck
header, without the individual spam assassin scores, though just
putting the SpamCheck header would probably work)


4) new actions:  bayes-ham, bayes-spam, auto-whitelist, auto-blacklist

    bayes-* will submit the message to sa-learn as either of those types
    auto-* will submit the message to sa-learn so that its addresses
will be added to the auto-whitelist with either a -100 score
(auto-whitelisting) or +100 score (auto-blacklisting)

     These actions would use the same files that had been used in the
spam check.



So, I might have (I might be misremembering score vs threshold, and
delete vs discard):

Low Ham Score = 0
High Spam Score = 10
Action Log = SYSLOG:local1

Low Ham Actions = bayes-ham auto-whitelist deliver
Ham Actions = deliver
Spam Actions = strip-html deliver
High Spam Actions = bayes-spam auto-blacklist log delete


(this counters the conventional wisdom of "don't auto-delete" because
you will have a record of who sent you that message, and the subject
... so you can manually whitelist them and ask them to resend if you
see something that looks like it might have been a false-positive)
(that's similar to what my procmail rules do now, except that I do more
of a permanent quarantine of spam messages than delete)

Then I might process the action log nightly/weekly/monthly to see if
there's a common sender or relay that is sending me the most spam, and
create an entry in my sendmail access db if they exceed a certain
threshold.