KevinTheJedi A couple of random things: We're using NGINX and Outlook, helpdesk has its own 365 email subscription, and we're using MariaDB for the database server.
Is there an incompatibility with any of this?
unpaidIntern
No, that's all fine. None of that would change the processing of emails and thread matching. Unless outlook modifies the raw emails or something but that's hardly ever the case.
Cheers.
KevinTheJedi I found an older post where you explained how the threading works. Can you explain it further? You said the system checks:
What tables would these be checking against? If ost_thread_entry_email only logs incoming emails, what table does the first test crossreference? Where are the original Message_ID's stored? What other criteria needs to be fulfilled if the Ticket Number isn't enough to connect them?
The code is open source and publicly available for review: https://github.com/osTicket/osTicket
When an email is sent from the system it generates a unique message ID with references encoded within. When the system gets a reference or in-reply-to value that came from the system we can decode it and lookup the references embedded within.
The Ticket number has to match, the sender has to belong to the Ticket, etc. You can follow the entire pipeline in the codebase.
If checking references encoded within message-id generated by the system then it checks the thread by id. Maybe entry id as fallback (I think, you'd have to double check code). If checking references from header that's not generated by the system then it checks the thread_entry_email table as I mentioned earlier.
There is no table that stores outbound message-ids as I mentioned above.
KevinTheJedi I was looking in class.mailer.php and I found decodeMessageID(). It looks like it wants a MID like this: <Bxxxxx-12345-BASE64TAG@my-domain> But mine look like this: SA1PR02MB8694A474F7ED35REDACT@REDACT.namprd02.prod.outlook.com
Would this cause any issues? I'm a bit confused how the code specifies that format, but the threading works for the replies to the new ticket made by the reply to the original autoresponse ticket.
I also updated to 1.18.4 and the issue still persists, it also still persists even if I disable my custom plugin.
The one you posted with outlook is not a message-id generated by our system so we cannot decode it. That would be used in the lookup stage for thread/entry matching.
KevinTheJedi I've noticed that the first post in the new ticket thread is the original ticket's auto-response and attached to that is my reply to it, is this normal behavior?
Can you show me what you mean?
Cheersl
KevinTheJedi The two tickets: Original ticket:
Reply to the autoreply ticket:
That was all of the thread, it was too big so I just split it into parts.
The first part of the autoreply ticket is the original auto-response sent out by the original ticket's creation, and when I reply to it the auto-response becomes a ticket and my reply becomes a comment.
The red blocks are me, and the green is just our domain. Helpdesk is the helpdesk email.
Something weird is definitely going on. Why no user message or response in the initial ticket? Shouldn't matter, just curious. As long as the Ticket owner or CC sends a message to the alert sent from the system it should thread through the existing Ticket.
So basically, when the Ticket is created it should send out a new Ticket auto-response to the User and associated CCs (if enabled). That auto-response email should have subject like "[#xxx] Subject Here" (judging by your screenshots - these can be modified in the templates). When a User or CC replies to that alert email its Message-ID (that should be in osTicket Message-ID format as it was sent from our system) would then be added to the In-Reply-To and/or References header in their email. Then when osTicket processes that email it should see the Message-ID from the In-Reply-To/References headers, decode it, lookup the matches, ensure everything checks out, then processes and threads the mail.
Also, the fact that you have a message with a white/gray bar means that that email came in and was associated but the system couldn't determine how it ended up there. Which indicates another potentially related issue with how you have your mail routing or something.
KevinTheJedi So the outgoing email should have an OSTicket message ID, it seems like somewhere along the way the header gets altered with an Outlook message ID and thats whats messing it up?
I looked at the routing rules and didn't see anything, I'm currently running a message trace so I'll get back to you with that.
I have zero clue what’s going on in your case so I’m not sure exactly. You can validate this yourself by creating a ticket, inspecting the new ticket auto-response’s raw headers, and making sure its Message-ID is an osTicket generated one. If so then when you click Reply/Reply All and reply as a user/CC the message you send should include the auto-response's Message-ID in the In-Reply-To/References header.
Judging by the screenshots this is the flow I see:
Then the subsequent new ticket is from a “helpdesk” email. Does the Helpdesk Bot user have the same email address as the system email you are fetching from? If so that’s your issue.
KevinTheJedi Right, we put it as an alias email
You cannot send alerts nor system messages back to the system email. So remove the Helpdesk Bot from your tests/flow and see if that works better.
KevinTheJedi So I removed the alias and that issue was resolved but its still making a new ticket, this time with the reply as the first post. I checked the headers again, message ID is not an OSTicket ID but it does match and is present in the reply's Reference and Reply fields.
I looked at the message trace and it looks fine. No routing rules apply either, save for a rule detecting that its an internal email and setting the scam confidence to -1.
The ID is still in the subject lines, too.
At this point you are going to have to show me screenshots of the whole flow. Like how you create the ticket and what the user email is. What email you receive the auto-response to and that you reply back from and how you send it. To what address that reply email gets sent to and where it winds up. What address and where the email is fetched from. Since you aren't using the hosted version I can't see anything. So you need to provide as much information as possible. Maybe post the headers of the alert you get, the email you send, etc.
Also include information like is the address getting the auto-response an alias of the system email that's fetching? Does the email that's fetching receive copies of emails sent to the user/agent emails? All the info you can think of to help us visualize the flow to get the fullest picture possible.
KevinTheJedi
Then a plugin is fired when the ticket creation event happens. It takes the information from the ticket and makes a task, ties it to the ticket, uses $thisstaff as the staff member, and sets the internal and default form data.
In my inbox I get this:
Now it takes about 5-30 minutes for it to show up despite me clicking around to trigger autocron, and despite the fetch frequency being 5 minutes. I'm also one of the few people testing the system so the 30 email fetch batch size shouldn't be a problem. (The orange part is a previous reply to the autoresponse that didnt output any debug information so I changed the error_log() lines and sent another reply.) (The ID slot being 3 more than the last one is just from 2 tickets being made before this one was made.)
This is the main and only email: The remote mailbox: SMTP:
The fetch email isn't an alias, the fetch email's inbox doesn't get copies of outgoing emails (except they show up in the Sent folder like normal).
I can get you the headers and class.thread.php/class.mailer.php function outputs too.
So the flow is:
If so then that doesn't really make any sense. The normal flow is Ticket is created, user gets auto-response, they can reply to that auto-response to update the Ticket, and the system will match based on email headers. That's how it works with thousands of setups/installs.
KevinTheJedi That's what I'm saying! Its so weird. I make sure to not reply to the agent's alert, and I only reply to my client alert.
Can you make a completely fresh install with no mods or custom plugins period, setup another system email, and test there?
