Attachments showing mime-type instead of file names

[tihomir-kit]

Hi,

It seems that attachments aren't showing filenames (at least for me). Here's what I see with the latest docker version of smtp4dev:

This is what it looks like with SMTP2 + Outlook (and it works and downloads without issues):

This is the raw email:

MIME-Version: 1.0
From: info@xxx.ie
To: info@xxx.ie, extra.email@xxx.ie
Date: 11 Aug 2020 14:46:17 +0100
Subject: xxx report for 10-08-2020
Content-Type: multipart/mixed;
 boundary=--boundary_1_1864c7ee-88b1-49b7-b81d-81be3a6922eb


----boundary_1_1864c7ee-88b1-49b7-b81d-81be3a6922eb
Content-Type: multipart/alternative;
 boundary=--boundary_0_15937200-de8f-468e-ae70-a3ac3df2edc2


----boundary_0_15937200-de8f-468e-ae70-a3ac3df2edc2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Please find the attached CSV files.
----boundary_0_15937200-de8f-468e-ae70-a3ac3df2edc2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Please find the attached CSV files.
----boundary_0_15937200-de8f-468e-ae70-a3ac3df2edc2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Please find the attached CSV files.
----boundary_0_15937200-de8f-468e-ae70-a3ac3df2edc2--

----boundary_1_1864c7ee-88b1-49b7-b81d-81be3a6922eb
Content-Type: multipart/mixed;
 boundary=--boundary_2_49d9f809-ead1-4757-9d76-3e955a87e3a3


----boundary_2_49d9f809-ead1-4757-9d76-3e955a87e3a3
Content-Type: application/octet-stream; name="application/octet-stream"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename=sub---2020-08-10-events-per-hour--20kph.csv

SG91cixDb3VudCBvZiBTcGVlZGluZyBFdmVudHMKMCwwCjEsMAoyLDAKMywwCjQsMAo1
LDAKNiwwCjcsMAo4LDAKOSwwCjEwLDAKMTEsMAoxMiwwCjEzLDAKMTQsMAoxNSwwCjE2
LDEyCjE3LDAKMTgsMAoxOSwwCjIwLDAKMjEsMAoyMiwwCjIzLDAK
----boundary_2_49d9f809-ead1-4757-9d76-3e955a87e3a3
Content-Type: application/octet-stream; name="application/octet-stream"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename=sub---2020-08-10-fastest-events--20kph-top10.csv

VGltZXN0YW1wLFNwZWVkCjEwLzA4LzIwMjAgMTY6NDgsODgKMTAvMDgvMjAyMCAxNjo0
OSw4OAoxMC8wOC8yMDIwIDE2OjUzLDg4CjEwLzA4LzIwMjAgMTY6NTQsODgKMTAvMDgv
MjAyMCAxNjo1NSw4OAoxMC8wOC8yMDIwIDE2OjU2LDg4CjEwLzA4LzIwMjAgMTY6NTcs
ODgKMTAvMDgvMjAyMCAxNjo1OCw4OAoxMC8wOC8yMDIwIDE2OjU5LDg4CjEwLzA4LzIw
MjAgMTY6NTAsODQK
----boundary_2_49d9f809-ead1-4757-9d76-3e955a87e3a3
Content-Type: application/octet-stream; name="application/octet-stream"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename=sub---2020-08-10-events-per-hour--35kph.csv

SG91cixDb3VudCBvZiBTcGVlZGluZyBFdmVudHMKMCwwCjEsMAoyLDAKMywwCjQsMAo1
LDAKNiwwCjcsMAo4LDAKOSwwCjEwLDAKMTEsMAoxMiwwCjEzLDAKMTQsMAoxNSwwCjE2
LDEyCjE3LDAKMTgsMAoxOSwwCjIwLDAKMjEsMAoyMiwwCjIzLDAK
----boundary_2_49d9f809-ead1-4757-9d76-3e955a87e3a3
Content-Type: application/octet-stream; name="application/octet-stream"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename=sub---2020-08-10-fastest-events--35kph-top20.csv

VGltZXN0YW1wLFNwZWVkCjEwLzA4LzIwMjAgMTY6NDgsODgKMTAvMDgvMjAyMCAxNjo0
OSw4OAoxMC8wOC8yMDIwIDE2OjUzLDg4CjEwLzA4LzIwMjAgMTY6NTQsODgKMTAvMDgv
MjAyMCAxNjo1NSw4OAoxMC8wOC8yMDIwIDE2OjU2LDg4CjEwLzA4LzIwMjAgMTY6NTcs
ODgKMTAvMDgvMjAyMCAxNjo1OCw4OAoxMC8wOC8yMDIwIDE2OjU5LDg4CjEwLzA4LzIw
MjAgMTY6NTAsODQKMTAvMDgvMjAyMCAxNjo1Miw4MwoxMC8wOC8yMDIwIDE2OjUxLDc4
Cg==
----boundary_2_49d9f809-ead1-4757-9d76-3e955a87e3a3--

----boundary_1_1864c7ee-88b1-49b7-b81d-81be3a6922eb--

Let me know if you need any extra info.

Thanks!

[rnwood]

Thanks for the example. It appears this is because we currently prefer the name attribute from content-type header if both that and the content-disposition filename attribute are present. I believe that's currently backwards, as the CD one is the newer RFC defined mechanism to communicate filename.

Watch out for a commit and build which will fix this shortly.