[rt-users] Creating tickets from mails without usercreation

[Paul Hirose]

On Fri, 11 Sep 2009, Stephen R. van den Berg wrote:
> If anyone is interested in the lighttpd setup, ask.

If you could toss it up onto the Wiki, that'd be great.  Searching the list for it would be second, if you decided to just email the instructions to rt-users.  Updated, known-good info is always nice :)

> - There is going to be spam eventually (yes, we try to filter it out
>  before reaching RT, but the filtering is bound to get worse over time).

All incoming mail at our site is filtered by our mail server and has nothing to do w/our RT setup.  I suppose you could add tighter, stricter filtering rules on top of your RT system but I think mail-filtering is best handled by your mail system.

But if you do decide to add additional filtering specifically for your RT system, we do it via procmailrc.  Our mail system runs ClamAV and SpamAssasin (like most places.)  It drops everything w/a Spam score of ## or more.  I lower that threshold specifically for incoming RT tickets.  You could further run a different spam filter (no sense running it through SpamAssasin twice), if you have a separate spam filter thing.

> - I need the mails to go into RT as tickets immediately.

I don't know how immediate things are.  But the delay for us has always been outside the RT system and is in the mail system.  If our mail system gets bogged down for whatever reason, then that obviously slows email delivery to our RT system.  But once it makes it to our RT system, it's "immediate".

> - I would like to erase some tickets permanently from the repository and
>  database (in case they are determined to be spam, keeping them in the
>  database won't work in the long run).

As mentioned above, we score incoming tickets for spam.  Anything with 10 and higher, we drop silently and it never makes it into our system.  Anything over 7 gets re-routed to a "spam" queue, no autoreply.  Anything under 7 makes it into the queue as normal.  We do that, just-in-case a ticket gets scored high for some reason.

Anything in the spam queue automatically gets deleted after 72hours.  Any spam/ticket that makes it into the real queue gets manually moved over by one of our staff into the spam queue (and then deleted after 72hours automatically.)

> - In order to keep database bloat to a minimum, the incoming mails should
>  not create users automatically.
> - If creating users is inevitable on initial import of mails, then it should
>  be possible for the user to be autoremoved again after the ticket which
>  created them has been removed.

I don't think you can NOT create a user/requestor.  But you can delete all unprivileged users from the database, that have no tickets or anything else "related" to them.  I think it's built-in to RT 3.8.5 (maybe 384).

See http://www.gossamer-threads.com/lists/rt/users/87446

Use rt-shredder (part of RT now, no need for the RTx::Shredder thing anymore) via a cron job (or manually from the web GUI.)

> - Ideally, at the time the tickets are moved (manually) from the incoming
>  queue to a specific queue, a user should be created automatically (just
>  like what happens currently), and the autoreply can be sent.

This you can do.  Get rid of the autoreply template for the incoming info@ queue.  That way, nothing gets sent out on initial email receipt/ticket creation.  Then, when you move a ticket from the info@ queue to the "real" queue, then set a Scrip to send a reply.

> - First receiving the mails in a separate mailbox and only then inserting
>  the mails into the system one-by-one is not really an option
>  because I have several persons which do the reading.

I'm guessing "separate mailbox" means a different email address, and "into the system" is referring to the RT system.  I realize you say this isn't the way you wanna do it, but it's do-able.  Have your mail incoming email address just be a normal mailbox.  Have all your several staff people all IMAP into it and they can delete as they see fit, and then "bounce" that email into the RT system.

As for how immediate that would be, would depend on how quickly your staff work.  I think this level of delay would be similar to the email going directly into the RT system and then waiting to be moved to the correct queue (and then getting the autoreply and presumably gets worked on.)

> If no, any hints on where/how to implement it?

I think manually deleting the ticket out of the system if it's a bad ticket, or moving it to the real queue if it's a good ticket is best.  Then delete unprivilged users that have no tickets associated with them.

PH

--
Paul Hirose          : pthirose at ucdavis.edu : Sysadm Motto: rm -fr /MyLife
1034 Academic Surge  : Programmer/Analyst   : Backup Motto : rm -fr /
One Shields Avenue   : Voice (530) 752-7181 : Robot, n.: Univ. Admin
Davis, CA 95616-8770 : Fax   (530) 752-4465 : rec.pets.cat.anecdotes