furioussnail Posted March 1, 2019 Report Posted March 1, 2019 Hello. Using latest Blesta version, 4.5.0. The ticketing system seems to be working properly only with {ticket_hash_code} in the subject. The problem with it compared to the {ticket.code} tag is that it breaks the conversation style in Gmail and similar email services. Relying on {ticket.code} should be enough. Or am I missing something? At least that's how majority of help desk software out there is working. Using {ticket.code} instead of {ticket_hash_code} in the subject line constantly generates new tickets. Thank you.
furioussnail Posted March 4, 2019 Author Report Posted March 4, 2019 I think this can be addressed by setting a more standardized hash. For example if admins set ticket subject to contain something like {company.code}-{ticket.id} Blesta could recognize the ticket as the same based on given format. This way Gmail and other similar email clients will be able to organize tickets properly. {company.code} could be an identifier like ACME for ACME Industries.
Paul Posted March 5, 2019 Report Posted March 5, 2019 {ticket_hash_code} is designed in such a way that Blesta can use it to identify the proper ticket, without leaving room for someone to maliciously modify the code to reply with updates to tickets that belong to other customers. It's designed with security in mind. ticket.id and ticket.code have direct relationships with real tickets, particularly ticket.id which is auto incrementing. Someone who receives a ticket with an ID of 100 can be reasonably sure that the ticket with an ID of 99 has already been created just before this one and is probably still open, and that ticket ID 101 will follow. Michael 1
furioussnail Posted March 5, 2019 Author Report Posted March 5, 2019 Uh, sorry. I meant {ticket.code} not {ticket.id}. Maybe matching a combination of "from" header (email address) with {company.code} (something like ACME) and {ticket.code} could solve this issue. Of course, if a message comes from another address it should be considered a different ticket. I see that some other platforms somehow manage to do. By the way, how does Blesta handle CC and BCC?
Michael Posted March 5, 2019 Report Posted March 5, 2019 On 3/5/2019 at 6:24 PM, furioussnail said: Uh, sorry. I meant {ticket.code} not {ticket.id}. Maybe matching a combination of "from" header (email address) with {company.code} (something like ACME) and {ticket.code} could solve this issue. Of course, if a message comes from another address it should be considered a different ticket. I see that some other platforms somehow manage to do. By the way, how does Blesta handle CC and BCC? Expand It doesn't work because the support manager is looking for the hash in the subject. It' show it ties it to the authorised ticket I believe. You could probably edit the support system to use the ticket.code but then I could open a ticket reply with your ticket.code if I knew it and just add a reply to the random ticket no authentication.
Paul Posted March 5, 2019 Report Posted March 5, 2019 On 3/5/2019 at 6:24 PM, furioussnail said: By the way, how does Blesta handle CC and BCC? Expand How do you mean? CC and BCC recipients receive a copy of the original email, so subject & body would necessarily be the same. If a ticket is sent to multiple recipients, then I think we'd generate each email separately and it wouldn't be a CC. The ticket hash provides necessary security and verification.. I forgot that I was composing this, and may have had more to say and got distracted. So, I'll leave it at this for now
furioussnail Posted March 5, 2019 Author Report Posted March 5, 2019 On 3/5/2019 at 7:35 PM, Blesta.Store said: It doesn't work because the support manager is looking for the hash in the subject. It' show it ties it to the authorised ticket I believe. You could probably edit the support system to use the ticket.code but then I could open a ticket reply with your ticket.code if I knew it and just add a reply to the random ticket no authentication. Expand The original "from" header can be used for matching.
Paul Posted March 5, 2019 Report Posted March 5, 2019 On 3/5/2019 at 9:44 PM, furioussnail said: The original "from" header can be used for matching. Expand That's right, but the headers can be spoofed, that's why the ticket hash. Michael 1
Michael Posted March 6, 2019 Report Posted March 6, 2019 On 3/5/2019 at 9:52 PM, Paul said: That's right, but the headers can be spoofed, that's why the ticket hash. Expand On 3/5/2019 at 9:44 PM, furioussnail said: The original "from" header can be used for matching. Expand and not just spoofed but if you have more than one ticket open how does that reply go to the correct one?
furioussnail Posted March 6, 2019 Author Report Posted March 6, 2019 On 3/6/2019 at 11:08 AM, Blesta.Store said: and not just spoofed but if you have more than one ticket open how does that reply go to the correct one? Expand I was referring to the "from" header in combination with the {ticket.code}. Or maybe I am missing your point.
Michael Posted March 6, 2019 Report Posted March 6, 2019 On 3/6/2019 at 4:01 PM, furioussnail said: I was referring to the "from" header in combination with the {ticket.code}. Or maybe I am missing your point. Expand That works I suppose if it's a current client what about people without a client account? With Blesta you can have more than one contact so that would also cause issues wouldn't it?
furioussnail Posted March 6, 2019 Author Report Posted March 6, 2019 On 3/6/2019 at 4:11 PM, Blesta.Store said: That works I suppose if it's a current client what about people without a client account? With Blesta you can have more than one contact so that would also cause issues wouldn't it? Expand A shadow, temporary account can be created for that.
Michael Posted March 6, 2019 Report Posted March 6, 2019 On 3/6/2019 at 4:17 PM, furioussnail said: A shadow, temporary account can be created for that. Expand more work to do? the simple way Blesta does it?
furioussnail Posted March 6, 2019 Author Report Posted March 6, 2019 On 3/5/2019 at 9:52 PM, Paul said: That's right, but the headers can be spoofed, that's why the ticket hash. Expand Probably for a general purpose billing system as Blesta the existing implementation is the best. In general email validation should be the concern of admins (talking server security administration). However, I actually appreciate how Blesta team built this. Thank you for your replies. I appreciate it.
furioussnail Posted March 6, 2019 Author Report Posted March 6, 2019 On 3/6/2019 at 4:20 PM, Blesta.Store said: more work to do? the simple way Blesta does it? Expand Yes, I realize that the way it is currently being done might be the best way for a billing solution for the masses. However, we also should realize that if someone manages to spoof a ticket message then hashing might not help. The attacker would require to to know both, the email address and the message title even without a hash. The way I see it, email address + ticket code + message subject makes for a good enough hash.
furioussnail Posted March 6, 2019 Author Report Posted March 6, 2019 This is a feature I think is worth having but at the same time I don't insist on it.
Recommended Posts