Research additional SMTP delivery policies and submission scheduling

[bbottema]

Why

SMTP submission does not necessarily end the sender's influence over how a message is handled. Besides DSN and REQUIRETLS, several standards let an application express delivery deadlines, mailbox-ownership checks, transfer priority, or server-side scheduling.

These could solve useful application problems, but an RFC alone does not establish useful server adoption or a good reason to expand Simple Java Mail's API. Research the candidates below before deciding which, if any, to implement.

This is unscheduled research, not a commitment to a release or to supporting every extension listed here.

Candidates

Mechanism	Why an application might want it	Important boundary	Specification
DELIVERBY (BY=)	Stop trying to deliver an expired notification, or request a notification when delivery takes too long.	A delivery deadline, not Simple Java Mail's send timeout. Return and notify modes behave differently; onward relay support matters. It does not guarantee delivery before the deadline.	RFC 2852
MT-PRIORITY	Ask servers to prioritize operational alerts over less urgent mail.	Server transfer priority, not simply the importance flag shown in an inbox. Servers apply their own policies; investigate relay behavior and optional header tunneling.	RFC 6710, RFC 6758
RRVS (Require Recipient Valid Since)	Reduce the risk of sending a password reset or account notification to someone who acquired a recycled email address.	A per-recipient mailbox-ownership continuity check using a timestamp, not proof of a person's identity. Requires usable ownership information and defined behavior when support or that information is absent.	RFC 7293
MAIL FROM AUTH=	Preserve the original submitter's identity through a trusted relay chain.	Not the SMTP login command, a password, or an end-to-end cryptographic signature. Propagation depends on authentication and trust rules.	RFC 4954, section 5
FUTURERELEASE (HOLDFOR / HOLDUNTIL)	Submit now and let the submission server hold the message until its scheduled release time.	Submission-server scheduling, not a policy carried through every relay, and not a guarantee of arrival at that time. Server limits and operational controls need investigation.	RFC 4865
TLS-Required: No	Deliver a message such as a TLS-misconfiguration report when normal destination TLS policy would prevent it.	An explicit security-policy relaxation carried in a message header, not merely omitting REQUIRETLS. Its interaction with DANE/MTA-STS and REQUIRETLS needs careful treatment; never add it implicitly.	RFC 8689, section 3

Research questions

• Establish real server adoption from current implementation documentation and reproducible tests. Which submission services and relays support each mechanism, and under what configuration or trust restrictions?
• Trace what survives forwarding, alias expansion, and unsupported intermediate servers. Document rejection, fallback, expiry, and notification behavior without treating SMTP acceptance as final delivery.
• Identify supported Jakarta Mail / Angus hooks and provider limitations. Do not assume raw extension strings are sufficient, or bypass the provider's SMTP state machine.
• Assess whether each use case warrants public API. Any proposal should use friendly typed values, reuse Email defaults/overrides, and expose recipient-level settings only where they make sense. Avoid a generic raw-protocol-parameter API.
• Check interactions with DSN, REQUIRETLS, exact EML, DKIM, S/MIME, and OpenPGP. Header-based fallbacks can change signed content; RRVS header fallback can also disclose recipient addresses.
• Describe what can actually be reported in submission receipts and diagnostics, versus what requires a later server notification. Distinguish requested policy from confirmed use.
• For viable candidates, outline capability negotiation, safe failure behavior, injection protection, and tests for pooled reuse and the existing send modes.

Expected result

A short recommendation per candidate: pursue, defer, or do not expose, with its user benefit, interoperability evidence, security constraints, and likely API/provider cost. Create separate implementation issues only after that decision.

Related work

• SMTP robustness plan #722: context, not an automatic expansion of that plan.
• SMTP probe #733: a useful starting point for inspecting advertised capabilities; an advertised capability alone does not prove downstream behavior.
• Existing DSN work: ENVID #736 and recipient NOTIFY / ORCPT #738. Do not duplicate these here.
• REQUIRETLS and SMTPUTF8 / 8BITMIME / SIZE remain separate work in the existing plan. Representation and transfer requirements are different from most of the application policies above.
• IANA SMTP extension registry for registered extension names and references.