[rt-users] Spam control

[Bob Goldstein]

>
>This question might be more appropriate on another list, but I thought 
>I'd ask if anyone here has good spam solutions.  I was thinking I could 
>maybe run the message through procmail, which could look at the headers 
>and toss out anything with an X-Spam-Flag set to Yes. I'm not at all 
>familiar with procmail so I am not sure how to do this or how to pass on 
>the clean ones through to the rt-mailgate script.  Pointers or working 
>examples of the procmail approach or another would be greatly 
>appreciated!  I'm going to start reading up on procmail, but it would be 
>good to know if I'm even barking up the right tree.
>


We do exactly that.  (In our case, we have procmail call spamc
and then check the headers.  You wouldn't need that.)

We use qmail, so when mail comes in, it finds a .qmail-address
file, the moral equivalent of a .forward file.  In our case,
it might have this (all one line, but broken up here):

 | if [[ -r /usr/local/rt/production/accc_core_mods/etc/filter ]]; 
   then   
        procmail -m INSTANCE='accc' QUEUENAME='bluestem' 
	/usr/local/rt/production/accc_core_mods/etc/filter ; 
   else 
      cat; 
   fi 
 | /usr/local/rt/production/bin/rt-mailgate 
      --queue bluestem 
      --action correspond 
      --url http://helpdesk.uic.edu/accc



Basically, this checks to be sure the procmailrc file
(called "/usr/local..../filter" here) exists,
then calls procmail using that as an argument and putting the
incoming mail on stdin.  Procmail does its thing, and puts the
note on stdout, which is a pipe to rt-mailgate, and the
rest is standard RT.  

In our case, we run multiple INSTANCES of RT, and each instance
can have multiple queues.  So we pass "filter" the name of
the instance and queue, so that it can apply different rules
if it chooses to.  (Some queues/instances will only accept mail
from campus users, others will bounce certain replies to off-campus
users, and so forth.  We happen to write filter so that
it does INCLUDEs  to get any instance-specific and queue-specific
procmail rules. You may not need that complexity/flexibility.)

One caveat -- if procmail decides to eat the mail (if it's spam),
then rt-mailgate is still part of the pipe.  So you have to 
modify rt-mailgate very slightly so it doesn't create a ticket
if the input is null.  Here is a trivial patch to do that,
which I've just submitted to BP today:

*** rt-mailgate.in.orig Thu Aug 12 15:06:13 2004
--- rt-mailgate.in      Thu Aug 12 15:07:41 2004
***************
*** 436,441 ****
--- 436,444 ----
  # Read the message in from STDIN
  $args{'message'} = <>;
  
+ unless ( $args{message} =~ /\S/ ) {
+     die "$0: no message passed on STDIN!\n";
+ }
  
  if ($opts{'extension'}) {
          $args{$opts{'extension'}} = $ENV{'EXTENSION'};