Hi,This is a bit different to most of the other posts I see about email ticket generation.I want to NOT generate a new ticket from email.I want our staff to raise tickets for our customers, and have the customer to be able to respond to existing tickets.But I do not want to have the system generate a new ticket from a email.I have email collection working, and it is updating tickets, that already exist, so that is working fine.But I don't want to have the system generate tickets from a new email. Two reasons, the first is the role that OSTicket will be used for, and also SPAM. If our OSTicket email address gets out to spammers, the system will become unworkable is very short period of time.How is everyone else stopping spam generating tickets in OSTicket.I have found out where to switch off auto-respond for the email, and that stops OSTicket sending a response, but it still creates a ticket, even if it doesn't auto-respond.If there is a setting, or tick box, that sorts this I can't find it. I have goggled and searched for the best part of a week and to no avail.Any guidance appreciated.Thanks-Gavin

First, to avoid spam, I suggest to use a spam blocker (appliance/system) and not osTicket.

You can use ticket filters to filter incoming mail and e.g. only allow tickets from "@your.domain.com".

Have not tried to filter out NEW mails, but maybe that is also possible via the ticket filters. Just test a bit with the ticket filters ;)

We use a Barracuda Spam Firewall.

Thank you for your replies.We are using a Sophos Email appliance ES100 to manage our email protection, so SPAM is considerably sorted before it gets to OSTicket.But, the main core reason, still remains, I want our staff to raise tickets for our customers, and have the customer to be able to respond to existing tickets. Not have the customers raise tickets via email.This system will be used as a provisioning and order management tool, and the associated informational updates and support requirements that this task requires.But we want to put the orders into the system, not have them generated by a customer deciding to email it. We have a support ticketing system for general support using OSTicket and this is working fine, and we expect customers to email this.Once a service is handed off/provisioned then it is supported by a different group of staff.As much as you tell a customer that, they are on the whole lazy. If they have a problem, then they will email the team that kept them up to date when the system is being installed (its easier to hit reply on an old email instead of writing a new one and finding the correct email address). That is happening now. So our provisioing staff then have to re-raise the ticket in the correct system, delete it from the provisioning system, advise the customer that they sent it to the wrong team. And guess what, next time the customer still sends it to provisioning. Why, because they don't care about the time involved or the fact it is two different teams of staff, last time the thing got fixed, so they keep doing it the same way.If the system bounced it and forced them to use the correct system, I wouldn't have to have a staff member spend up to 2 hours a day transferring things to across to support. Also the customer would have things fixed quicker because it would be going to support, not to staff that can't help him. (essentially provisioning are mainly clerical staff)On other software that I used at another organisation a few years ago, it was simply a tick box. 'Do not create tickets from new emails'. It allowed replies to be attached to existing tickets, but bounced new emails with a canned response, explaining that they are emailing the wrong team when it was a new email and gave them a mailto: link for the correct system. System worked great.I will try again to see if I can find a combination of ticket filtering to work. I have been playing with that over the last week or so. Problem being, if I filter out new tickets, I filter out replies also, there is no means of differentiating the two via ticket filtering that I can find at the moment.

2 years later
Write a Reply...