Skip to content

Add plain text alternative to email messages#7122

Merged
ramyaragupathy merged 2 commits intohotosm:developfrom
heathdutton:bugfix/5595-add-plain-text-to-emails
Feb 23, 2026
Merged

Add plain text alternative to email messages#7122
ramyaragupathy merged 2 commits intohotosm:developfrom
heathdutton:bugfix/5595-add-plain-text-to-emails

Conversation

@heathdutton
Copy link
Copy Markdown
Contributor

What type of PR is this? (check all applicable)

  • 🍕 Feature
  • 🐛 Bug Fix
  • 📝 Documentation
  • 🧑‍💻 Refactor
  • ✅ Test
  • 🤖 Build or CI
  • ❓ Other (please specify)

Related Issue

Fixes #5595

Describe this PR

Emails sent by Tasking Manager only include an HTML body. Email clients that display plain text by default show empty messages.

This PR adds a plain text alternative to all outgoing emails by:

  • Using FastAPI-Mail's alternative_body parameter with multipart_subtype=alternative
  • Auto-generating plain text from HTML when not explicitly provided

Review Guide

The change is in backend/services/messaging/smtp_service.py. The _send_message method now sends multipart/alternative emails with both HTML and plain text parts.

@sonarqubecloud
Copy link
Copy Markdown

@prabinoid
Copy link
Copy Markdown
Collaborator

prabinoid commented Jan 8, 2026

Thank you @heathdutton for this. But, it seems like the emails received are on plain text even when email clients supports rich texts like html. Is it the case? I think we might want to keep the html by default for sent messages as most clients do support formatted/Rich text by default.

@heathdutton
Copy link
Copy Markdown
Contributor Author

@prabinoid The original issue #5595 was that plain-text email clients (like mutt) showed empty messages because emails only had HTML, no plain text fallback.

The fix should send both HTML and plain text in a multipart/alternative structure, where the client picks its preferred format. HTML clients should still see HTML.

@prabinoid
Copy link
Copy Markdown
Collaborator

Hi @heathdutton , I tested out the PR and it seems gmail (supports html by default) shows only the plain text part and doesn't render out html which should be otherwise as shown in other image:
Screenshot 2026-02-02 at 11 46 27
Screenshot 2026-02-02 at 11 51 22

From Gmail → Show original, it looks like the multipart/alternative is malformed — the HTML part appears before the plain text, and the multipart container itself seems to be base64-encoded. Maybe that’s causing Gmail to fall back to the plain text? Would ensuring text/plain comes first, text/html second, and that the multipart container isn’t base64-encoded solve the issue?

@heathdutton
Copy link
Copy Markdown
Contributor Author

Sorry for stalling, just a bit confused because FastAPI-Mail attaches HTML then plaintext, but RFC 2046 says that the preferred format should be last. I think maybe we should swap body and alternative_body for now rather than try to fix fastapi-mail. Standby.

https://www.rfc-editor.org/rfc/rfc2046.html

Swap body and alternative_body so plain text comes first and HTML last.
Per RFC 2046, the preferred format should be last in multipart/alternative.
@sonarqubecloud
Copy link
Copy Markdown

sonarqubecloud Bot commented Feb 4, 2026

@ramyaragupathy ramyaragupathy merged commit 9237327 into hotosm:develop Feb 23, 2026
9 of 13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Validation mail has no text part

3 participants