You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
The text was updated successfully, but these errors were encountered: