Extend allowedFileTypes in attachment or make config parameter

[dimyy]

https://github.com/espocrm/espocrm/blob/6224d8fbbe9c7972f8aa38e51cf7de864c1dcc66/application/Espo/EntryPoints/Attachment.php#L52

Some email pictures imported with types
'image/jpg',
'application/octet-stream'
and then hot shown.

Please extend list of allowed types or make config parameter

[dimyy]

And another one:

Add

strtolower($fileType)

Some attachments imported like image/PNG

[yuri]

I added strtolower in attachment import.

I don't think it's right to enable application/octet-stream for image rendering.

[dimyy]

It may be more correct to focus on exif_imagetype()?

or use

$file_info = new finfo(FILEINFO_MIME_TYPE);
$mime_type = $file_info->buffer($entity->get('contents'));


Mime type and extension are not the correct path to determine the file type.

[yuri]

> Mime type and extension are not the correct path to determine the file type.

I don't think that checking mime-type is not a correct way. The type can be not recognizable by it contents. Maybe we need to use both methods, use finfo as a backup mechanism for types like application/octet-stream. I'm not sure.

If a file does not contain a mime-type in its contents, there's no reliable way to know its type other than from a body-part header and an extension (we don't use). All methods are just guessing.

From wiki:

An associated file is the mime.types file, which associates filename extensions with a MIME type. If the MIME type is properly set, this is unnecessary, but MIME types may be incorrectly set, or set to a generic type such as application/octet-stream, and mime.types allows one to fall back on the extension in these cases. Similarly, since many file systems do not store MIME type information, but instead rely on the filename extension, a mime.types file is frequently used by web servers to determine MIME type.

Could you provide any email (original) with an application/octet-stream image so I could test the import.

[dimyy]

In private message