Edit: Please see emails at bottom.
L.S.
Just upgraded to 21.3.75 desktop edition on Windows 10. When I send an invoice an email with attachment.bin as attachment is produced instead of a properly named pdf invoice.
Possible bug?
Kind regards, Arjen
Yes the attachment show properly named within Manager, but not so in the actual email message sent.
Thunderbird will show this to be a PDF document and will preview it. This is due to the content type.
Content-Disposition: attachment; filename=attachment.bin
Content-Transfer-Encoding: base64
Content-Type: application/pdf; name=attachment.bin
However, some other email clients as well as invoice processors and regular users do not know how to handle a file named attachment.bin
Seems like problem with your email service than Manager
What email server are you using?
I am using protonmail via the proton mail bridge.
Verified in another administration using gmail. → No issue
Thunderbird via Proton bridge → no issue.
It is something to look into some more if this is some special interaction between the bridge and manager. I do think that Proton is only looking at the message envelope/headers and not at it’s contents.
In additon, I ran wireshark on the connection to the bridge. The attachment is named correctly.
Content-Type: application/pdf; name="nameofinvoice.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; read-date="Wed, 07 Apr 2021 13:19:47
+0000"; creation-date="Wed, 07 Apr 2021 13:19:47 +0000";
modification-date="Wed, 07 Apr 2021 13:19:47 +0000"
I surmise looking at the protonmail bridge code that they do expect the filename parameter to be present in Content-Disposition. Was this Header field recently added?
I have found some relevant information. There is some linguistic ambiguity in the documentation of the relevant RFC. Which has been discussed and concensus seems to be that the filename parameter should be present in the Content-Disposition header.
Relevant urls and quotes:
https://en.wikipedia.org/wiki/MIME#Content-Disposition
Many mail user agents also send messages with the file name in the name parameter of the content-type header instead of the filename parameter of the header field Content-Disposition. This practice is discouraged, as the file name should be specified either with the parameter filename, or with both the parameters filename and name
The following discussion is referred to:
https://mailarchive.ietf.org/arch/msg/ietf-smtp/KtN0TdoHDayKvKycNbsFD-GB-e4/
Finally, if you have to include filename information, either put it in a
filename= parameter or both a filename= and name= parameter. Never ever use
just a name= parameter
Perhaps this can be logged as a bug with the upstream library used to for the mail functionality?
Recap: The attachments can possibly not be seen by software application / mail clients handling incoming PDF invoices. Bug can also be triggered by a secure email gateway. (Proton in my case).
Well, that would be .NET 5.0
Filename paratemer as per RFC has some outdated restrictions like max 8 character filenames and ASCII characters only. The world has moved on from this many many years ago.
So I assume .NET 5.0 is not using filename parameter at all because of these restrictions and is using non-standard name parameter instead.
I don’t think Microsoft would consider this a bug. They’ve done it on purpose.
Thank you for taking the time to reply. I dove into this rabbit hole some more and found that there is actually a second incantation for this parameter called filename* which takes an odd formatted UTF8 url encoded filename to work around the historic format. For reference example here: browser - How to encode the filename parameter of Content-Disposition header in HTTP? - Stack Overflow
Nevertheless RFC’s discern between MUST, SHOULD, MAY (and perhaps more) this is a SHOULD and not a MUST. So the library is compliant, however they COULD REALLY implement the filename* 