Hi all.
I wanted to check that this would be basically sound practice…
We have a small use RT system, and it’s getting a lot of spam,
and we’d like manual control over the users that can view the tickets
inside the system for other reasons anyway.
I could set up spamassassin/spambayes, but I thought to kill two birds
with one stone, and only allow pre-approved users access and
create-ticket rights.
Would the simplest way to do this be to deny ‘everyone’ all rights,
make one or more groups that have the basic rights (create ticket,
seequeue etc), and assign users that we want in the system to the new
groups?
Will this stop ‘spam’ and other unauthorised users creating accounts
on the system automatically when they try (and fail) to create a
ticket?
http://wiki.bestpractical.com/index.cgi?ManualAdministration
mentions that whenever anyone mails RT, it creates an account for them.
Basically, what I’m after is the ability to either stop that happening,
make it reliant on my approval,
or a reason why this isn’t a good approach.
Apologies for the basic nature of the question. I could not find the
right answers on the wiki or in the mailing list archives. Must be a
braino day.
–Benji
Would the simplest way to do this be to deny ‘everyone’ all rights,
make one or more groups that have the basic rights (create ticket,
seequeue etc), and assign users that we want in the system to the new
groups?
Sure won’t work here. We can’t maintain an up-to-date
list of who’s allowed to ask us questions. We have 40,000
clients, and since many use off-campus email addresses,
I have to all ‘everyone’ to create tickets.
We’ve set up procmail ahead of RT. Instead of piping the
note into mailgate, we pipe it into procmail, and then pipe
the result into mailgate. When we run procmail, we have a
generic .procmailrc, and we put the queue name (and RT instance
name, since we run multiple instances) in the environment.
That enables the procmailrc to ‘include’ some other
proccmailrc’s on a queue-specific basis, if we want to
have special rules for a given queue.
I wouldn’t call it simple, but the upshot is that procmail
calls spamc, and drops anything that spamassassin labels
spam. It then can enforce other requirements (against
attachements or maybe certain email addresses) and can
bounce messages where it’s not spam, but there is somthing
else wrong that we want fixed before it even gets to RT.
The flexibility is good, and SA is good enough to cut out
almost all the spam. If you can limit your clients
to a fixed list of pre-created RT accounts, that would
work, too.
bobg
We’ve set up procmail ahead of RT. Instead of piping the
note into mailgate, we pipe it into procmail, and then pipe
the result into mailgate. When we run procmail, we have a
generic .procmailrc, and we put the queue name (and RT instance
name, since we run multiple instances) in the environment.
That enables the procmailrc to ‘include’ some other
proccmailrc’s on a queue-specific basis, if we want to
have special rules for a given queue.
…I could just have it run a simple filter for ‘authorised email
addresses’ and only ever
pass those on to RT, but I wanted to hear what others would say about
just doing it from
inside RT… 
…If I can, it seems less kludgy, easier to maintain by my non-unixy workmates.
–Benji