On Tue, Aug 18, 2009 at 17:54, Michael Bravo<mike.br...@gmail.com> wrote: > No, that would be a cop-out, but would kind of defeat the whole endeavour. That's an interesting characterization of free advice that doesn't meet your changing criteria.
> Perhaps I wasn't clear enough - I already have a large number of customers > entitled to e-mail support. And they do have the magic codes. Also, for the Yes, which they could use to authenticate. > considerable majority of my customerrs, e-mail is more accessible and > convenient than web. At least to start the support request. As such, the > workflow I outlined is more or less a necessity - accept e-mail, parse the > magic code, and either auth the user and create the ticket, or autoreply and > no ticket. Then, you're going to have to do a lot of monkeying around with an RT::Interface::Email::Filter. I'd start with the existing SpamAssassin.pm (Fail if sender + magic cookie are invalid). You don;t get a lot of control over the failure message though. But really, the "Email" thing is a red herring. All you really need to do is have all inbound tickets go into a (temporary queue), and use a scrip to verify tickets and move the legitimate ones to a real queue / reject the freeloaders. This should be very simple with ExtractCustomFieldValues. See recent thread on doing something with a dummy CF field value. -- Cambridge Energy Alliance: Save money. Save the planet. _______________________________________________ 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