I'm not sure if this is going too far. It would probably be a good idea to at least leave headers like Content-Type and Content-Transfer-Encoding in place?

On a side note - why do additional headers bother you? Can you not just ignore them when parsing the decrypted part?

The emails i want to send have touchy subjects and it only encrypts emails if the user requested to do so. The application is not suppose to decode the message but rather the user himself since if he asked to encrypt some of his emails and provide the public key, he should be able to proccess the message on his own, means i'm not dealing with whatever the decrypted message says. With that in mind I see no purpose on having all the headers inside the encrypted block message since that is essentially garbage for the user.

If you just want to put encrypted text into the body of an email for your users to decrypt it however they see fit, you could simply do that without using this gem at all. Any PGP/MIME compliant client will not display these headers anyway and PGP/MIME compliant client libraries will allow easy retrieval of the body as well. Definitely the headers aren't 'garbage' - leaving them in means the receiver can trust them since they are part of the encrypted / signed payload.

I'm not sure about how PGP/MIME compliant clients will handle an encrypted email that would be generated using this method. Can you add a test showing that decryption of a body_only encrypted email with this gem still works (also for multipart emails)?

Once i got the complaints about the header i actually considered simply straight up encrypting the text however my team was quite pleased on how simple and clean the code looked like so i was asked to try and look for a workaround, whichlead me to dig into the source code. The code is working just fine in my local environment nevertheless once i have some time i'll write the tests you requested.
Thanks for the hard work