Spam control

RT Users
1

Due to the nature of our RT helpdesk the email address has to be
published in public space (both virtual and real - web pages and paper
flyers around the department :slight_smile: and as such, it wasn’t long before the
spammers scraped it up. I’m looking to do a bit of spam control before
the mail hits the helpdesk and creates spurrious tickets.

I have a mail server running a Postfix/amavisd-new/SpamAssassin setup so
recognizing the email as spam is not a problem. The issue is that for
most users of this mail system, we still want to deliver the mail and
let them set client-side filters to deal with the spam as they see fit
based on the X-Spam headers added to their email. However, for RT
helpdesk mail, we’d probably want to just discard these messages.

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.

Thanks,
Fran

Fran Fabrizio
Senior Systems Analyst
Department of Computer and Information Sciences
University of Alabama at Birmingham

205.934.0653

2

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’};

3

If you already have procmail setup for local delivery, the recipe itself
is pretty easy:

:0:

  • ^X-Spam-Flag: YES
    /home/rt3/spam.mbox

I have this in the /home/rt3/.procmailrc file to save anything marked as
spam to a regular mbox file instead of passing it to the regular mailbox
(which I use fetchmail to pickup). You could just as easily discard it
with:

:0

  • ^X-Spam-Flag: YES
    /dev/null

I can’t help if you don’t have procmail setup already since I use
sendmail instead of Postfix, or if you deliver directly to rt-mailgate
with an alias.

HTH

Derek

Fran Fabrizio wrote:

Due to the nature of our RT helpdesk the email address has to be
published in public space (both virtual and real - web pages and paper
flyers around the department :slight_smile: and as such, it wasn’t long before the
spammers scraped it up. I’m looking to do a bit of spam control before
the mail hits the helpdesk and creates spurrious tickets.

I have a mail server running a Postfix/amavisd-new/SpamAssassin setup so
recognizing the email as spam is not a problem. The issue is that for
most users of this mail system, we still want to deliver the mail and
let them set client-side filters to deal with the spam as they see fit
based on the X-Spam headers added to their email. However, for RT
helpdesk mail, we’d probably want to just discard these messages.

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.

Thanks,
Fran

Derek Morris
El Modeno Gardens, Inc. 1 (800) 776-8111
dmorris@elmodenogardens.com extension 252

4

We are a small company, with some hundreds customers registered for support;
so we chose to protect RT using TMDA http://tmda.net/ . This is an
open-source challenge-response system. This allows us to have a completely
spam-free database. Whenever a new customer does not reply to the challenge,
the mail is delivered by hand; in our configuration, this is an unusual
issue.

.-. Robert GRASSO - CEDRAT S.A.
/v\ 10, Chemin de Pre Carre - ZIRST - 38246 MEYLAN Cedex - FRANCE
// \ Tel: +33 (0)4 76 90 50 45 Fax: +33 (0)4 76 90 16 09
/( )\ mailto:Robert.Grasso@cedrat.com
^^-^^
UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things. – Doug Gwyn
Support service : mailto:support@cedrat.com
Commercial service : mailto:cedrat@cedrat.com
Web site : http://www.cedrat.com

5

Robert Grasso wrote:

We are a small company, with some hundreds customers registered for
support;
so we chose to protect RT using TMDA http://tmda.net/ . This is an
open-source challenge-response system. This allows us to have a
completely
spam-free database. Whenever a new customer does not reply to the
challenge,
the mail is delivered by hand; in our configuration, this is an unusual
issue.

I don’t know your special situation, but from my own experience I can say
that challenge-response systems create even more spam for completely
unrelated users when their address has been used as the sender address in
spam. When I get this kind of backscatter spam, I usually block the
challenge sender.
Please consider using other facilities such as RBLs for spam reduction
first.

Wouldn’t it be much better, since you know who your customers are, to
whitelist them and return a mail rejection message in the SMTP dialog when
an unlisted sender tries to send mail to your RT mail address? That
approach only creates backscatter when the mail is getting in via an open
relay host, and it’s that host’s responsibility to fix it…

Cheers,
Hans-Martin

6

I don’t know your special situation, but from my own experience I can say
that challenge-response systems create even more spam for completely
unrelated users when their address has been used as the sender address in
spam. When I get this kind of backscatter spam, I usually block the
challenge sender.
Please consider using other facilities such as RBLs for spam reduction
first.

Wouldn’t it be much better, since you know who your customers are, to
whitelist them and return a mail rejection message in the SMTP dialog when
an unlisted sender tries to send mail to your RT mail address? That
approach only creates backscatter when the mail is getting in via an open
relay host, and it’s that host’s responsibility to fix it…

I set up TMDA one year ago; 6 months before (nearly), I was discovering and
installing RT V2. There was no tool allowing to cleanup or archive any kind
of ticket (dead tickets, tickets from the past year …). And on our
business addresses, we use to receive hundreds of spams per day. RT V2 and
its lacking of archiving tools led me to set up a rather harsh solution, in
the same time that I was learning to deal with spam, generally. (BTW, RBLs
are only one part of the solution against spam; could they be sufficient,
everybody would be happy, and spam would not exist any more)

As I can only spend a few time administering RT, it’s only a few months ago
that, browsing the mailing lists, I discovered contributed cleanup tools - I
downloaded them and … some day I will test them. Meanwhile, without spam,
the database went beyond 1GB and is slowly growing … just guess its size
if it had been badly protected …

Maybe RT V3 integrates cleanup and archiving tools ? which could change my
anti-spam policy. I will discover it … soon, as soon as I read the doc :wink:

Anyway, our customers base is still evolving, so I cannot state : “our
allowed customers are in this whitelist, we will reject anybody else”. Just
think about new employees (with brand-new addresses) hired by an old
customer. And as we are a small company, we cannot plan to setup a system
such as a web portal were customers can manage an account, register allowed
people which will be able to contact us. It’s not possible - not soon,
anyway.

I understand what you say. I may change my anti-spam policy, but if I do, as
spam is the problem that we know, it will be with great care - only with
great care.

Best regards
Robert

7

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 just started using RT here and have had to deal with the spam problem
also. Here is what I have built for my Tech Support address, so far:

BEGIN ~support/.procmailrc
LOGFILE=procmail.log
VERBOSE=on
COMSAT=no

The Barracuda says the message is spam so don’t put it in RT; but deliver

it to the Tech Support people just in case it is legit.

:0

SpamAssassin says the message is spam so don’t put it in RT; but deliver

it to the Tech Support people just in case it is legit.

:0

Various cronjobs have historically had their output sent to the support

address. Route them around RT.

:0

Keep bounce messages from creating infinite loops.

:0

  • ^FROM_MAILER
    ${DEFAULT}

Otherwise, send it to RT.

:0w
! tech-support@rt.example.com
END ~support/.procmailrc

Scott Lambert KC5MLE Unix SysAdmin
lambert@lambertfam.org