Is there any disadvantage of "Precedence: bulk" in RT emails header

RT Users
5

We use DSPAM and its Quarantine instead of the bogofilter+SPAM folder
here, but it is basically the same idea and it works very well indeed.

KenOn Fri, Jan 04, 2008 at 03:33:14PM +0000, Mark Chappell wrote:

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

The rt-users Archives

SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:

If you sign up for a new RT support contract before December 31, we’ll take
up to 20 percent off the price. This sale won’t last long, so get in touch
today. Email us at sales@bestpractical.com or call us at +1 617 812
0745.

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media. Buy a
copy at http://rtbook.bestpractical.com