[rt-users] Spam filtering in RT

[Bill Cole]

Venkateswaran, Subbaraman wrote, On 7/6/09 10:05 AM:
>
>
> Hello everyone,
>
> Would like to understand what's the best strategy to stop spam emails
> creating tickets in RT ? Thanks for your time.

That's a bit like asking "what's the best vehicle?" without mentioning what 
sort of transportation you need.

RT gets used in so many different types of environments that a perfect 
anti-spam solution for one site may be completely useless elsewhere. I've 
worked with RT in three very different places, and spam control in each has 
been very different. Some generally useful principles:

1. Do as much of your spam stopping as you can in the MTA layer, not in the 
mail gateway delivery agent or RT itself.

2. Segregate your RT mail from all other mail. Ideally, the domain part of 
the addresses that deliver into RT will only be used for RT mail, so you can 
have spam control for it that is not compromised by the needs of other 
recipients in the domain. When that is not possible (e.g. public role 
accounts like abuse-reporting addresses) you will still benefit from having 
some mechanism that treats RT's mail differently before it gets handed off 
for delivery into RT.

3. If you don't need to accept requests from random strangers, don't 
configure RT to autocreate users when receiving email from random strangers. 
This alone (sometimes in conjunction with something like 
RT::Authen::ExternalAuth that can autocreate RT users based on an external 
user database) is adequate for many circumstances.

4. Use the per-queue address mechanism (built into 3.8, previously in the 
BrandedQueues extension) so that you can segregate correspondence on 
existing tickets from new-request mail, and filter the two streams 
accordingly (e.g. require mail to a queue-specific address to have the right 
RT Subject tag) using whatever tools your MTA has or can hook into.

5. Think carefully about how RT's legitimate incoming mail in your 
environment differs from a generic mail stream aimed at a large set of 
people, and use that (see #1) to tune its filtering. Spam control is done 
best when it is customized for a specific well-understood mail stream rather 
than generically. A mail stream into RT is very unlikely to look like a mail 
stream into a bunch of corporate users' mailboxes or into a consumer ISP's 
users' mailboxes or into a sysadmin's mailbox. Tactics that would do 
violence to personal mail might be harmless and effective for RT's incoming 
mail, and vice versa.

6. Be prepared to adjust your filtering of RT's mail in response to spam 
coming in.