Privacy incident about mailanalyzer HOT 32 CLOSED

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

from mailanalyzer.

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

from mailanalyzer.

I will try that

from mailanalyzer.

oups

from mailanalyzer.

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

from mailanalyzer.

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

from mailanalyzer.

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.

from mailanalyzer.

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.

from mailanalyzer.

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

from mailanalyzer.

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

from mailanalyzer.

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

from mailanalyzer.

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

from mailanalyzer.

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

from mailanalyzer.

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.

from mailanalyzer.

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

from mailanalyzer.

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

from mailanalyzer.

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.

from mailanalyzer.

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

from mailanalyzer.

After your validation, I'll package a new version

from mailanalyzer.

where is the file?

thank you.

from mailanalyzer.

in the mailanalyzer folder

from mailanalyzer.

In this file I only have 297 lines:

from mailanalyzer.

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

from mailanalyzer.

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

from mailanalyzer.

Hello, I can't try it this week,

from mailanalyzer.

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

from mailanalyzer.

Can I install on GLPI 10.0.10?

Thank you

from mailanalyzer.

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

from mailanalyzer.

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

Thank you

from mailanalyzer.

Hello @AlexTR85
Yes
Thank you,
Regards,
Tomolimo

from mailanalyzer.

Ok, installed, let's see if everything is perfect ;)

Thank you

from mailanalyzer.

Hello!

I'm going to close the ticket, I've already received an email with the ID <> new and those records haven't entered the database, but the email has, so it's working correctly.

Thank you!

from mailanalyzer.