Skip to content

gmail +send --html should emit multipart/alternative (parity with +reply-all) #793

@culstrup

Description

@culstrup

Summary

gws gmail +send --html currently produces a single-part text/html message, while gws gmail +reply-all --html produces multipart/alternative (HTML + a plain-text alternative). Behavior parity across the helpers would be useful.

Current behavior

$ gws gmail +send --to me@example.com --subject test --html --body '<p>hi</p>'
$ gws gmail users messages get --params '{"userId":"me","id":"<id>","format":"metadata"}' \
  | jq .payload.mimeType
"text/html"
$ gws gmail +reply-all --message-id <msg> --html --body '<p>hi</p>'
$ gws gmail users messages get --params '{"userId":"me","id":"<id>","format":"metadata"}' \
  | jq .payload.mimeType
"multipart/alternative"

Desired behavior

+send --html (and +forward --html if applicable) emits multipart/alternative with two parts:

  1. text/plain: strip-tags fallback of the HTML body
  2. text/html: the user-supplied HTML body

Why it matters

  1. Some corporate spam gateways slightly down-weight text/html-only mail vs. multipart.
  2. Text-only clients and accessibility tools have no fallback content.
  3. Helper-to-helper consistency: +reply-all already does this; +send should too.

Implementation note

The compiled binary already references multipart/alternative, and +reply-all's codepath produces it, so the MIME composer supports it. Looks like a small wiring change in the +send helper to plumb the alternative-part construction.

Version

gws 0.22.5 (macOS x86_64).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions