Hi
When I change RexEx in line 114 to /^[a-z-]+/[/*a-z0-9.+-]+$/i I start receiving new error messages
Laminas\Mail\Header\ContentType::setType expects a value in the format "type/subtype"; received "multipart/mixed"

How to fix it...?

It's rather unclear what are you even trying to do, what is the problem in question.

It's rather unclear what are you even trying to do, what is the problem in question.

Sorry. I will try to add full details.
From the start I have problems when GLPI trying to receive some mails with images in attach. This look like "Laminas\Mail\Header\ContentType::setType expects a value in the format "type/subtype"; received "image/*"" message in logs. To fix this issue, the RegEx at the file "laminas-mail/src/Header/ContentType.php", line 114 changed to /^[a-z-]+/[/*a-z0-9.+-]+$/i . This does not help. GLPI stop receiving any mails and I see new error messages in log "Laminas\Mail\Header\ContentType::setType expects a value in the format "type/subtype"; received "multipart/mixed""

Looks like The XY Problem, you think the problem is about regex, but not described the actual problem. you need to make a reproducible scenario for a library like laminas-mail, with describing clearly what are the expectation.

you can upload the reproducer as https://gist.github.com/ or (i think) attach a .zip file to issue tracker works too. the reproducer should be standalone and minimal to show clearly the problem. include copy of the email in question.

Could this be causing a strange side effect of our incoming email tickets being given prior ticket numbers?

Tried the adjustment above, having same effect as warmech777

There is def something wrong in here and I think it caused my prior issues, I'm going to go look at this files history.

I essentially just commented out 114-120, and it seems to have resolved my problems. I'll keep an eye on this thread for the proper fix.

Well, this got rid of the errors in mailgate, but still having my issue of new tickets occasionally assigning to old ticket ID's. Looking else where.

Ok, I'm bumping this issue since I've got the same situation while reading messages. It appears that 'Samsung Email on Android' generates an 'image/*' content-type for images.

Here is a link to the gist: https://gist.github.com/rikvdh/489e13b22f9012db2dcd9f5046b53e43
I think changing the regex would be the way to go as a workaround for this issue. In the end, it is an issue in the mail-client of the user.

The regex should be

/^[a-z-]+\/[\*a-z0-9.+-]+$/i

instead of

/^[a-z-]+\/[/*a-z0-9.+-]+$/i

as suggested on glpi-project/glpi#8375 (comment)

Hello,
I also came to this issue with an email sent from a smartphone...
And the issue has been fixed using the following regex: /^[a-z-]+/[*a-z0-9.+-]+$/i
Thank you,
Regards,
Tomolimo

Technically, this is a not a valid content type. RFC 2045 allows either IANA registered type or private subtype prefixed with x-. Considering that it is neither and it is not even a real content type that did not bother to go through registration procedure, content type image/* is a BUG in composing software.

However, as per RFC 2045 image/x-* is a valid content type:

https://datatracker.ietf.org/doc/html/rfc2045#section-5.1

 token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
             or tspecials>

 tspecials :=  "(" / ")" / "<" / ">" / "@" /
               "," / ";" / ":" / "\" / <">
               "/" / "[" / "]" / "?" / "="
               ; Must be in quoted-string,
               ; to use within parameter values

Overall, image/* makes no sense but should be allowed for the purposes of this library.

Hello @Xerkus
Yes I totally agree with you, but we have no choice, we cannot loose incoming emails sent from smartphones (for example) even if they do not respect 100% the RFC.
Thank you
Regards,
Tomolimo

This library is used for composing emails and it does not make a distinction between parsed non-conforming email and composed non-conforming email. Invalid composed emails can not be allowed. For this reason rejecting invalid email is preferable.

Could it be then that an additional (optional) parameter can be used to inform the method that we are in the process of analyzing received emails, in order to differentiate composition or reception?

@Xerkus Not only composing emails. Together with IMAP/POP this is also used for reading in emails from external clients, which can be anything. ofc it is not according RFC. But don't get me started on mails not conforming RFC.

@tomolimo See #146

Hello @rikvdh
We had in the past exactely the same issues as mentioned in #146 and I made a small modification in the source code to enable non-strict validation of domains in email addresses...
thank you
Regards,
Tomolimo

I'm currently maintaining a fork with a lot of those exceptions commented out. I would like to think of something which could become mainline (like a function to turn those exceptions off). But this is quite convoluted when in your application message-decoding is 'abstracted' behind an 'imap-client' and some checks are deeper in other repo's.

https://github.com/rikvdh/laminas-mail/tree/v2.25-non-strict

This is the same case for us, we are using GLPI (= ITSM), which in turns is using laminas-mail for the emails input, see glpi-project/glpi#8375