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. _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com