Hello everyone,
Would like to understand what’s the best strategy to stop spam emails
creating tickets in RT ? Thanks for your time.
Thanks
Subba Venkateswaran
A&T - App Eng - SEG
609 282 7015
THE INFORMATION CONTAINED IN THIS MESSAGE AND ANY ATTACHMENT MAY BE PRIVILEGED, CONFIDENTIAL, PROPRIETARY OR OTHERWISE PROTECTED FROM DISCLOSURE. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.
Hello everyone,
Would like to understand what’s the best strategy to stop spam emails
creating tickets in RT ? Thanks for your time.
Once you are “sure” of how effective your general spam filtering is, you
simply need to stop any e-mails classified as spam from every entering RT.
You cannot succeed 100% though, so what you perhaps need to do is to
redirect any such e-mails to a queue on RT where there is no autoreponse
scrip.
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
“If you have nothing good to say about someone, just shut up!.”
– Lucky Dube
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:
-
Do as much of your spam stopping as you can in the MTA layer, not in the
mail gateway delivery agent or RT itself.
-
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.
-
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.
-
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.
-
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.
-
Be prepared to adjust your filtering of RT’s mail in response to spam
coming in.