Enabling anyone to submit tickets

Have more questions? Submit a request


  • Dee Quilliams

    Can we get the flag notification moved? It covers some of the text of the customer's comment and so we have to copy and paste it elsewhere to see what we are missing. It is only a few characters, but in cases where they are providing critical info or times of day, etc. we need to see everything.

  • Jessie Schutz

    Hi Dee! Do you think you could post a screenshot of what you're experiencing? I just want to make sure I understand exactly what you mean.

  • alvaro

    The problem is that my tickets are not showing Attachments, im using the 3 agents version account.
    How can I solve this issue ?

    Also how can I set automatic verification for all emails ?

    I only need email support for the moment.

  • Jessie Schutz

    Hi Alvaro!

    You'll need to make sure that your attachments are not exceeding the size limit for your plan type. That's usually the culprit in this situation.

    If you're doing email-only support, you don't need to worry about verifying customer emails, because they will not need to log in to your Help Center.

    Please let me know if you have any other questions!

  • Will Strohl

    When you enable the ability for customers to register or anonymously submit a new ticket, what's the URL for them to do this?

    Also, if you force registration, can you still submit tickets via the API without registration?

  • Justin Smith

    Hey Will!

    There isn't a special URL that is enabled for users when you allow then the ability to submit tickets anonymously. The system just allows them to submit a ticket through your email chat or web form channel without registering for an account first.

    Regarding the submission of tickets through the API, whether or not the ticket is suspended depends on how you setup/make the API call. If you're passing in the ticket of an unauthenticated user using an admin/agent credentials in the call, it will create a brand new user and allow that ticket into the account. If you setup something like a custom html ticket form which utilizes the end-user credentials for authentication, that will cause the ticket to be suspended just the same as if an unauthenticated user sent in an email.

    I hope that helps but feel free to reach out if you have any follow up questions :)

  • Will Strohl

    Thanks for the answer. I looked into it more. The reason I was asking was because I couldn't see where/how a customer might ask a question. I was going to try and figure out how to add it. That part of the UI is hidden to me since I'm an agent/admin. When I looked while not logged in, I saw it just fine.

  • Pat Prince

    It's very disconcerting that this article doesn't mention a major vulnerability that this feature opens up and has recently been exploited: that choosing to have an "Open" instance means that you're also allowing access to a web form that allows anyone to spoof the email address of any user with little to no difficulty.

    The URL is the standard ticket submission URL (https://yourinstance.zendesk.com/hc/en-us/requests/new).  However, if you have an "Open" instance, you don't need to be signed-in and you are given a new field called "Your email address" where you can enter any email address you want and Zendesk will accept it without question or challenge.

    You can take a look yourself by opening an incognito window and going to https://support.zendesk.com/hc/en-us/requests/new - you'll see this problematic field after selecting "What can we help you with today?".

    I've voice concerns about this before to support agents and I've already been told that this is just what an "Open" instance is.  However, there is a world of difference between the ability for me to send an email from my own email address to have ticket created and allowing me to type in any email address without challenge or verification.

    Today our Zendesk instance effectively got hijacked via this feature and turned into an spam email server!  It wasn't even that difficult!  They had a list of people they wanted to spam and just had to recursively enter their spam message into the Subject & Description and kept entering the spam recipient into "Your email address" field.

    I'm following the process and have created a "Feature Request" (https://support.zendesk.com/hc/en-us/community/posts/360004237847-Feature-Request-Provide-More-Control-Over-Ticket-Submission-Methods-For-Restricted-Instances), but this really seems to very obviously be a security vulnerability that Zendesk needs to address ASAP.  Uncouple the "anonymous submission" forms (the Web Forms Channel) from the ability to receive unknown email addresses (the Email Channel) or better manage anonymous Web Form Channel submissions and that should address the issue.

  • Max McCal

    Hi, Pat - 

    I'm Zendesk's product manager focused on Abuse Prevention, and this is our largest concern right now. We're actually working on a campaign to improve this in several ways, and will be sending out messages to every unsecured account before the end of this year. Here are some changes we're investigating:

    1. We've already enabled reCAPTCHA on all new accounts, and recommend that all existing accounts do the same. Attacks like the one you experienced are almost always scripted, and we've seen a simple CAPTCHA stop them in their tracks over and over. We're also getting ready to update this to the new invisible CAPTCHA form, reducing its interruptions to the experience of legitimate users.
    2. We're removing the placeholder {{ticket.comments_formatted}} from the "Notify requester of received request" trigger of all new accounts as well, and recommend that existing accounts do the same. By preventing ticket creation from sending out a duplication of spam content, the sort of attack you experienced is ineffective (or at least greatly reduced in effectiveness), because the spam messages aren't sent via email.
    3. We are exploring ways to keep the API endpoint that powers this web form from accepting requests from unknown parties. Even with CAPTCHA in place, we will need to look at ways like this to stop attacks that might not pass through the user interface.
    4. We need to implement an option that requires users to log in before submitting tickets. This would be a little bit more stringent than enabling "Ask users to register" as an option, but not as closed off as turning off "Anybody can submit tickets". 

    We think that pursuing all of this will help us to fight these issues, and we're already in the process of addressing them. I'd love to know your thoughts

  • Pat Prince

    Hi Max,

    Thank you for the quick response.  It's good to hear that there are already plans in the works to address this issue.  I wanted to bring two concerns to the forefront:

    1. From our perspective, the real problem isn't the massive amount of extra ticket (which is a pain, but definitely addressable without too much trouble).  The real problem is that our company name, our brand, our product, and our email address are now the face of a 17k+ email spam campaign to and from political / geographic regions that are currently experiencing political / social friction.  We have no idea yet how this will potentially affect our reputation / brand in the near or far future.  I understand that it's being addressed, but I wanted to be clear that this goes far beyond just an annoyance of a bunch of extra tickets being created and stands to have a real effect on our business.
    2. Will the fourth change you mentioned prevent the abuse of this "Your email address" field in the Web Form Channel, while still allowing us to immediately receive a ticket from a previously unknown email address via the Email Channel (without waiting on the user to register / verify)?  If so, that would address our business needs.  If not, that would be problematic as that is the crux of our needs in order to allow our business model to continue uninterrupted while still protecting our Zendesk system from abuse.


    Thank you,

    Pat Prince

  • Max McCal

    Hey, Pat - 

    To your first point, I completely understand. It's been having a very real effect on our own, as these emails are sent by our servers. The capacity for this to affect our ability to send any email for any of our customers is huge, and that's why it's become such a priority for us. I appreciate you keeping us engaged on this. 

    The fourth change would prevent the abuse because it would require an email address to be verified before the first ticket can be submitted, and would prevent abuse from that point on by requiring sign in (whether with user/password, or Google, Facebook, Twitter, Microsoft, or SSO) to submit tickets. It would be "immediate", but it would require sign in and verification on the customer's part. Without those, though, there's no way for us to guarantee that the person entering the email address is the same as the owner of the email address.

    This is ultimately why we're spending our energy on locking down API endpoints, and investing in CAPTCHA. It is also why I would strongly recommend updating your "notify requester of receive request" trigger (or equivalent) so that it does not contain a placeholder that replicates comments. By removing it, you vastly reduce the attractiveness of your account to spammers.


Please sign in to leave a comment.

Powered by Zendesk