Support multipart/alternative, rather than just /mixed, ideally with nesting

When using attachments, swaks will use multipart/mixed for the container, and each attachment becomes a sibling in it.

But, this is not always desired.

Sometimes a user may want multipart/alternative for the container, or they may want a nested structure, with sub-parts within sub-parts.

Some relevant discussion here: https://stackoverflow.com/questions/3902455/mail-multipart-alternative-vs-multipart-mixed/23853079#23853079

I guess at a minimum, it would be good to be able to specify the type of the top-level multipart container.

A more thorough feature would be to support an arbitrary nested structure of MIME parts.

There is a nod to this issue in that, if multiple bodies are added using --attach-body, multipart/alternative is used. Essentially the 'body' component of the message is special and can have explicitly set alternative parts. Every other attachment is multipart/mixed. If this should satisfy your need but isn't working, let me know because it's a bug. Otherwise it's a feature request and I don't have an ETA. This is part of the "how much do I want to be a test tool specifically for SMTP and how much do I want to be an easy, command line MUA" argument I'm having with myself over the future of swaks

if multiple bodies are added using --attach-body, multipart/alternative is used.

Ah, my version of swaks (20181104.0) does not have --attach-body. Looks like that came around 2020 — sorry for not checking latest!

I tried it, and it does work as advertised. I was able to create the mail I originally wanted with:

$ swaks --to $USER@localhost --attach-type text/plain --attach-body @mail.txt --attach-type text/html --attach-body @mail.html

Otherwise it's a feature request and I don't have an ETA. This is part of the "how much do I want to be a test tool specifically for SMTP and how much do I want to be an easy, command line MUA" argument I'm having with myself over the future of swaks

Understood (:

I do find myself using it for reason # 2 most often, but I know feature creep's a pain.