Hello, I just installed OTRS and one of my main worries right now is that each time a ticket is opened by a customer, my agents need to log into the web interface. Now, I've googled long and large the archives for those kind of problems and found a few trails: Email driven OTRS: http://lists.otrs.org/pipermail/otrs/2003-December/003384.html Email to tickets: http://lists.otrs.org/pipermail/otrs/2004-June/005504.html The latter is particularly interesting. In it, it is mentionned that allowing external mails to be considered "agent-generated" is a security issue. Well, I don't agree with that: I think that with strong cryptography, email can be quite trustworthy. My general idea is to allow agents to reply to customer requests all through email, using PGP-signed emails. In fact, not only could they reply as agents, but they could also manipulate the state of the ticket all through email, and, provided PGP is properly setup, this would be totally secure, and maybe even more efficient than the web interface. The way I see it, a few modifications would be needed to make this work: 1. modify Kernel/System/Ticket/Article.pm::SendAgentNotification() to put the customer email as a From: instead of the OTRS email. The queue email should be put in Cc, but with the "Header" param of the Send() function otherwise we'll get a nice mail loop. :) This is to allow the agent to easily answer to the customer directly, through email. 2. add crypto logic to Kernel/System/PostMaster.pm::run() to authentify the agent email. if the agent is not authentified, the email is considered to be a simple followup. 3. add command possibilities to the above run(). commands similar to the Debian bugtracker could be implemented. Priority should be given to the usual "close". A list of commands: * close {success,failure} -- close the ticket, defaults to success * hold <date> -- put the request on hold * client <newclient> -- to change the client * agent <newowner> -- to give to another agent * merge <id> -- merge with another ticket * link {ticket,faq} <id> -- to link to another object * priority [1-5] -- change priority * lock/unlock -- lock/unlock the ticket * move <queue> -- move to a different queue * bye -- stop interpreting commands those commands would be embeded in the body of the email or in special header(s). both would be equally interpreted. if the first line of the body doesn't correspond to one of those parameters, it is disregarded and not interpreted as a command. commands that can have comments will have their comments filled in with the response from the agent. Most of this sounds almost trivial to me, apart maybe from the crypto logic. Now, I would be ready to start working on this. What I want to know is: * Would it be proper to accept commands from any key configured in the global keyring, or should each agent have a key assigned? * Would such a modification be accepted in the core or would I have to maintain this as an external patch? * Are people interested? I hope the answer to all of the above is a enthousiastic "YES!" have a good one, a. PS: this "design document" (let's not be afraid of words :) is available at: http://wiki.koumbit.net/OpenTicketRequestSystem/MailBased