Privacy incident

[AlexTR85]

"I have a GLPI 10.0.9 with plugin 3.0. I have experienced an incident. I have several recipients, an email was sent to 2 of those recipients, and for some reason, the email ended up as a response to a ticket that has nothing to do with it, neither with the client nor with previous messages. I have seen the SQL that created an empty message_ID: < > It has only happened to me once that I am aware of, but it is a very serious privacy issue."

I don't understand the criteria used to associate that email with that ticket.

[tomolimo]

Hello @AlexTR85 I don't have idea of the path that leads to this, but what I sugest to you is to delete this record from the table. Thank you Regards, Tomolimo

[AlexTR85]

If an ID message < > is repeated, tickets and emails will cross paths again. It is not possible to add validation to prevent them from entering or being registered with the message_ID < >

Thank you

[AlexTR85]

I have been running tests: I can't locate any logs that can indicate where the issue is. The issue persists with version 10.0.10.

The emails arrive with the correct ID, which I verify in the header. These are emails sent to a single recipient, although I have several recipients.

I had to create a ticket with the message ID <> in the database in the plugin's table to capture these emails and prevent them from going to a ticket for a different client, where information might cross between clients. In such cases, I change the ticket ID in the database because the emails add their ID correctly. That's why I don't understand why the plugin associates the message ID <> randomly with emails.

I don't see where the problem is, and there are no records in the logs, or I can't find them.

I don't know how to help you, or if you've located the issue.

[wwc-ca]

I found something that may be interesting/helpful. I'm running GLPI 10.0.7 and the latest MailAnalyzer, and have had new threads from different senders added as followups to existing (unrelated) tickets. Going through the headers, I found one interesting thing--the Thread-Index for the thread-opening email is the same for these unrelated email threads, and it probably isn't supposed to be. In our company, our users have a "Support Request.msg" file on their desktops addressed to our support account, with a generic "Support Request" subject and a few questions to answer. Reading a little about the Thread-Index header, it sounds like Thread-Index is generated from Thread-Topic, something called "FILETIME", and a GUID. I wonder if this specific circumstance--a pre-filled Subject field (Thread-Topic), a widely distributed and identical .msg file used as a template and perhaps retaining some of the same metadata (FILETIME?), could consistently create the same Thread-Index for the thread-opener, and the plugin is associating them to the wrong ticket based on that. I'm going to remove the pre-filled Subject from the deployed .msg file, and will be happy to share results of different Subject fields if you're interested, or provide any further info if you think it's worth looking into.

[tomolimo]

Hello @wwc-ca This could be an answer, but not sure that this is the root cause for @AlexTR85 issue. By the way do not use .MSG as template for new emails to tickets: it leads to the behaviour that you describe. On the contrary, you may use real email templates (.OTF). From these, Outlook will create new Thread-Topic each time you'll create an email from an OTF.

To create a template from a .msg:

1. go to the File menu,
2. click on "save as",
3. and choose "Save as type" 'Outlook Template (*.otf)'

And distribute this OTF to your end-users, and you will be sure that Thread-Topics will be differents.

Thank you Regards, Tomolimo

[tomolimo]

Hello @AlexTR85 I would like to try to reproduce the issue. Could you post a zip containning an MSG (one or several) which leads to this behavior? Of course if you can reduce the email content to the minimal size that reproduces the issue that would be good. If you prefer, you can use Discord to post the zip: my account is Tomolimo Thank you Regards, Tomolimo

[wwc-ca]

Hello @tomolimo, Thank you, the .msg file as a template has always bothered me, but it's never caused enough problems to worry about fixing it--I'll definitely do that now. For what it's worth, I just reproduced the issue with a brand new .msg "template" with pre-filled To and Subject lines. Changing the Subject line at all must refresh it enough to generate a unique Thread-Index--a dozen messages from the .msg file with the prefilled subject will have the same Thread-Index and add them to the same ticket, but manually appending " 1" to the Subject every time will create new tickets for each one. Good luck tracking down the issue, let me know if I can provide any more info to help. Thanks! Chris

[AlexTR85]

Hello @AlexTR85 I would like to try to reproduce the issue. Could you post a zip containning an MSG (one or several) which leads to this behavior? Of course if you can reduce the email content to the minimal size that reproduces the issue that would be good. If you prefer, you can use Discord to post the zip: my account is Tomolimo Thank you Regards, Tomolimo

hello!!

I have found the issue; the emails have two message-IDs, one belonging to the email itself and the previous references for each response. Some emails, when forwarded or replied to, strip that chain, leaving the field empty. I suppose by implementing a condition (IF reference: <>, do not add ID), this could be resolved. Normal mail: Mail with issue:

Can you fixe it?

Thankyou

[tomolimo]

Hello @AlexTR85 Thank you for the deep analysis Yes I'll fix this Thank you, Regards, Tomolimo

[tomolimo]

Hello @AlexTR85

I tried with and still can't reproduce the issue... Could you post a minimal EML file that triggers the issue?

Thank you, Regards,

Tomolimo

[AlexTR85]

hello,

Did you try adding a space after "References:"?

I'll see how I can send you an email without information; they are incident emails and contain a lot of information.

Is it not possible to add a condition so that it never generates an entry <> in the database? That way, at least the incident is marked as resolved.

Thank you.

[tomolimo]

Hello @AlexTR85 In fact, the regexp that is used to match the "References" is: /<.*?>/g in hook.php line 303 So you can see that it matches only when there is a < and a >, spaces only will not match at all. Thank you, Regards, Tomolimo

[tomolimo]

So I think the only way to reproduce is to have References: <> or References: < > but not an empty line

[tomolimo]

I will try that

[AlexTR85]

You are right, if it were a " " in the CMDB, it would come out empty, but it loads the symbols "<>" without anything inside. Could it be an interpretation? The result is that it generates "<> " in the database with no content between the symbols <>. There is no such combination in the email headers, so I believe it's an interpretation it generates.

[tomolimo]

I made a fix, could you try it? in hooh.php replace line 308 by return array_filter($messages_id, function($val) {return trim($val, '< >') != '';}); Thank you

[tomolimo]

After your validation, I'll package a new version

[AlexTR85]

where is the file?

thank you.

[tomolimo]

in the mailanalyzer folder

[AlexTR85]

In this file I only have 297 lines:

[tomolimo]

oups

[tomolimo]

I have a more recent version, I'm going to provide a new release then

[tomolimo]

See release 3.1.1 https://github.com/tomolimo/mailanalyzer/releases/tag/3.1.1

[tomolimo]

Hello @AlexTR85 Do yo have news? Did you test? Thank you, Regards, Tomolimo

[AlexTR85]

Hello, I can't try it this week,

[tomolimo]

Hello @AlexTR85 Do yo have news? Did you test? Thank you, Regards, Tomolimo

[AlexTR85]

Can I install on GLPI 10.0.10?

Thank you

[tomolimo]

Hello @AlexTR85 I've tested it on the 10.0.12, but it should be compatible with any 10.0.X Thank you, Regards, Tomolimo

[AlexTR85]

Hello, To update the plugin, do we just need to replace the folder and that's it?

Thank you

[tomolimo]

Hello @AlexTR85 Yes Thank you, Regards, Tomolimo