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 root@localhost Fri Oct 13 16:17:56 2017
Delivered-To: abs@localhost
From: <root@localhost>
To: <abs@localhost>
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