Details
-
Problem report
-
Status: Reopened
-
Trivial
-
Resolution: Unresolved
-
None
-
None
Description
While testing another issue, I needed to send some notifications as examples to my local machine.
Using claws-mail as my main mail-client, the problem doesn't manifest as, being claws-mail smart, it will decode any base64 mime content in plain text.
But I was lazy to switch window and I just used the standard "mail" command for reading my mbox and this appeared:
From [email protected] Fri Oct 13 16:17:56 2017 Delivered-To: [email protected] From: <[email protected]> To: <[email protected]> Subject: Resolved: Test trigger Prova 1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 UHJvYmxlbSBoYXMgYmVlbiByZXNvbHZlZCBhdCAxNjoxNzo1NSBvbiAyMDE3LjEwLjEzDQpQcm9i bGVtIG5hbWU6IFRlc3QgdHJpZ2dlciBQcm92YSAxDQpIb3N0OiBQcm92YSAxDQpTZXZlcml0eTog QXZlcmFnZQ0KDQpPcmlnaW5hbCBwcm9ibGVtIElEOiA5MDY3DQo=
I didn't tried to change the configuration for not using curl, need more investigation, but, IMHO, the e-mail body plain utf-8 text should not be encoded as mime-multipart.
As a use case, it can happen that a sysadmin need to open the e-mail "just" with mail or any text editor. Also, this is not standard for canonical text