1092 Add MIME type for attachments

Closes #1092 (closed)

What does this MR do?

Why is the change needed?

Email attachments which are retrieved via IMAP are stored without a MIME type. This results in an incorrect Content-Type header when downloading these attachments. For instance, downloading a PDF attachment will have a Content-Type of text/html which causes Firefox to open the file as an HTML file instead of opening the PDF reader.

How is the change addressed?

When the attachment is stored, its MIME type is determined by the mime_content_type function (analogously how it is done for attachments which are uploaded via the webclient for the @foodsharing.network addresses).

Remarks

• I first thought that we could just retrieve the MIME type from the email, but looking at https://github.com/ddeboer/imap/blob/45eb4913de20c0065648fe8ddf5c6427d46d0b87/src/Message/AbstractPart.php and https://github.com/ddeboer/imap/blob/master/src/Message/Attachment.php, I could not find any method that would provide this functionality. Therefore, I opted to reading the MIME type from the file after it was stored on the file system.
• There are no tests for MailsControl.php file yet. I didn't start writing a test as I believe it would require a rather big rewrite to make the class easier to test because in the current state we cannot easily inject mocks, but this may just be due to a lack of in-depth PHP testing knowledge.

How confident are you it won't break things if deployed?

Even if the mime_content_type function fails to determine the file type, it will not throw an exception (see https://www.php.net/manual/en/function.mime-content-type.php). Thus, adding the content type in the IMAP retrieval process should not break. Furthermore, even if the content type is set to false (return type of the mime_content_type function when the content type could not be determined), it will not be used when downloading an attachment because there is already a truthyness check in place when generating the attachment response.

How to test

For details, see https://foodsharing.de/?page=bezirk&bid=734&sub=forum&tid=145836 (German).

1. Go to the mailbox
2. Open an email with a PDF attachment
3. Click on an attachment and in the download dialog click on "open with..."
4. For all emails that are fetched after this change was deployed, the attachment schould open correctly. For all emails fetched prior to this MR, the attachment will be opened as an HTML file which obviously prevents the file from being displayed correctly, e.g. when openening a PDF file. The faulty behavior was observed in Firefox.

Checklist

• added a test, or explain why one is not needed/possible...
• no unrelated changes
• asked someone for a code review
• set a "for:" label to indicate who will be affected by this change
• used "state:" labels to track this MR's state until it was beta tested
• added an entry to CHANGELOG.md
• added a short text that can be used in the release notes
• Once your MR has been merged, you are responsible to create a testing issue in the Beta Testing forum: https://foodsharing.de/?page=bezirk&bid=734&sub=forum
  • Consider writing a detailed description in German.
  • Describe in a few sentences, what should be tested from a user perspective.
  • Also mention different settings (e.g. different browsers, roles, ...) how this change can be tested.
  • Be aware, that also non technical people should understand.

Release notes text in German

E-Mail Anhänge in "@foodsharing.network" Postfächern werden nun mit der richtigen Applikation geöffnet, wenn im Download "Öffnen mit" ausgewählt wird.