Investigate first-class email template support and integrations

[bbottema]

Context

Simple Java Mail accepts rendered plain text and HTML through the existing email builder. Applications commonly produce that content with Thymeleaf, Freemarker, Mustache, Pebble, or their own rendering layer.

That boundary is simple and works today, but it is worth investigating whether Simple Java Mail could provide something genuinely useful around templates instead of stopping at documentation.

There are already adjacent capabilities:

• reply quoting supports a narrow %s-based HTML layout;
• embedded-image auto-resolution was introduced in Add support for dynamic datasource resolution (file/url/classpath) for embedded images in HTML body #260 partly for HTML templates that can change without corresponding Java changes;
• the Spring module could provide an integration point without making Spring or a template engine mandatory.

Investigation

Compare the value and cost of these directions:

1. Keep the current render-then-build model and improve only examples and documentation.
2. Introduce a small engine-neutral extension point for producing plain-text and HTML message content.
3. Add optional integrations for one or more established template engines.
4. Provide focused helpers for concerns that repeatedly occur around email templates, such as paired plain/HTML output, embedded resources, or reusable model data.
5. Let the Spring module discover an application-provided renderer or adapter without coupling core modules to Spring Security or a template engine.

Also investigate actual user demand, maintenance cost, Java 8 compatibility, dependency weight, escaping and trust boundaries, and whether an abstraction would remain useful across materially different engines.

Constraints

• No mandatory template-engine dependency in the core library.
• Avoid locking the public API to one engine or framework.
• Preserve the existing ability to pass final body strings directly.
• Keep reply-quoting templates conceptually separate from general message rendering.
• Template escaping and model-data safety must have a clear owner.
• Any future public API or module should follow the API expansion workflow.

Outcome

Produce a recommendation covering:

• documentation only, engine-neutral API, optional integrations, or another useful addition;
• the proposed module and dependency boundaries;
• a small representative API sketch when code changes are recommended;
• compatibility and migration impact;
• whether the result belongs in 10.0.0 or can ship independently.