[rt-users] Is there any disadvantage of "Precedence: bulk" in RT emails header

[Mark Chappell]

Asrai khn wrote:
>> We tend to be fairly aggressive on our spam checking when it's going
>> into RT, with procmail dumping the mail into a separate mail folder if
>> it even suspects that the mail is spam.
>>
> How you achieve this ? imean would you care to share the process/script of
> dumping spam to separate email folder?

Since you're using Postfix which I don't really know I'll do most of 
this as an outline, and our procmail script is fairly custom do I'll 
only quote chunks of the procmailrc.

The first line of defense are our front-line mail relays.  These reject 
on various DNS rbls and add headers for several others.  The lists we 
use include SpamHaus' full zen list, SpamCop, MAPS and SORBS.  They also 
run a copy of spam assassin WITHOUT any of the baysaen stuff turned on, 
a high enough spam score causes an out right rejection at the end of the 
SMTP DATA time, and leaves a header in the message for lower scores.  We 
also reject on Virus signatures using the, and have some extra 
signatures to pick up certain types of phishing scams 
(http://www.sanesecurity.co.uk/).  Any rejection at this stage is done 
before we've actually accepted the mail, so backscatter (which I would 
guess is what caught you out) is seen to come from the server sending 
you the spam NOT from your servers.

This is how we treat almost all incoming mail, rejecting approximately 
90% of mail before it's even through the front door (with surprisingly 
few complaints about mail not getting through given the number of users 
we have from "spam friendly" countries).

The second line of defense is procmail.  The mail server on our RT 
servers don't deliver directly to RT they deliver to the procmail 
command, which eventually delivers to RT.  Procmail runs a batch of 
extra checks, including; a baysaen filter using "bogofilter", 
"renattach" which catches certain types of attachments, "nodupmail" 
which catches certain types of mail loops, "double clicks" and general 
duplicated mail, and some custom stuff so that certain queues only see 
mail sent via a specific web form.  If bogofilter or the earlier lower 
spamassassin threshold are triggered then we drop the mail into a "SPAM" 
mail file.  We have a couple of perl scripts which allow us to identify 
"privileged" users out of RT and lets them bypass most of the procmail 
filtering.

The privileged check is basically a perl wrapper around some simple RT 
code with a little bit of caching built in.

====
my $user = RT::User->new($RT::SystemUser);

$user->Load($username);

unless ($user->Id) {
     exit(1);
}

foreach my $key qw(Name EmailAddress RealName Privileged Disabled) {
     my $value = $user->$key;
     print($key.": ".$value."\n");
}
====

Getting procmail to run external commands is straight forward

For example here's some of our bogofilter and spam assassin stuff

====
BOGOFILTER=/usr/bin/bogofilter
BOGOFILTER_SPAM_ARGS="-c /etc/bogofilter-SPAM.cf"
BOGOFILTER_MD_ARGS="-c /etc/bogofilter-MD.cf"
SPAM_ASSASIN_RESULT="`formail -xX-Spam-Flag: | grep -i yes | awk '{print 
$2}'`"

# SPAM - bogofilter.
:0fw
| $BOGOFILTER -e -p $BOGOFILTER_SPAM_ARGS
# on failure return mail to the queue, the MTA will try delivery later,
# 75 is the value for EX_TEMPFAIL in /usr/include/sysexits.h
:0e
{ EXITCODE=75 HOST }
# record the result.
BOGOFILTER_RESULT="`formail -xX-Bogosity: | grep -i yes`"

# a virus can bombard us with mta bounce messages because we were used in
# a forged "From" address, pick these out as they're valid messages despite
# being caused by a virus.
:0fw
| $BOGOFILTER -e -p $BOGOFILTER_MD_ARGS
:0e
{ EXITCODE=75 HOST }
MAILER_DAEMON="`formail -xX-MD-Bogosity: | grep -i yes`"

SPAM="$BLACKLISTED$SPAM_ASSASIN_RESULT$BOGOFILTER_RESULT"

:0
* ? test -n "$SPAM"
SPAM
====

Those final 3 lines are what tells procmail to deliver, literally into a 
file named "SPAM" if there's any content in the $SPAM variable


Mark
-- 
Mark Chappell
Unix Systems Administrator