I have 1.18.2 and some inline email attachments are not being picked up from mail, suspects are from Microsoft systems. I got these details from mail headers of one which was picked up and one which was not and fed it to chatGPT...
The one that works:
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=194538
Content-ID: <image001.png@01DC1B42.9CF16710>
Content-Transfer-Encoding: base64
Has inline Content-Disposition with a filename.
Content-Transfer-Encoding is correctly base64.
The Content-ID is simple, consistent, and doesn't include curly braces or long GUID-style IDs.
Email parser in OSTicket expects something like this to identify an attachment.
The one that fails:
Content-Type: image/png; name="d4b9a5b6-3117-41dc-acfa-e93c7dd0db9f.png"
Content-Description: d4b9a5b6-3117-41dc-acfa-e93c7dd0db9f.png
Content-Disposition: inline; filename="d4b9a5b6-3117-41dc-acfa-e93c7dd0db9f.png"; size=5430
Content-ID: <527be655-95e0-4bbb-bdc7-9cc74e8fdcf7>
Content-Transfer-Encoding: base64
The filename is a long GUID-like string, which OSTicket sometimes fails to parse properly.
The Content-ID is just a GUID without an @domain part. Some OSTicket versions expect a format like <file@domain>; otherwise, it may treat it as a “part of the message” rather than a standalone attachment.
Small attachments (like 5 KB in your example) sometimes get skipped if OSTicket’s parser thinks they are inline images referenced by HTML <img> tags, especially with non-human-friendly filenames.
Now the question I have is what do I do about it? I want these inline email attachments to be picked up on the tickets. Any ideas greatly appreciated please.
