Optional Local Delivery Notifications for Outbound Mail

Feature Ideas
1

Summary

Add an optional feature that allows Stalwart to generate local Delivery Notifications to the sender whenever the sender requests delivery notifications and Stalwart has definitive information about the message’s delivery progress.

This feature is not intended to replace RFC 3461 Delivery Status Notifications (DSNs), nor should it fabricate information that is not known. Rather, it would generate informational notifications based solely on what Stalwart itself has observed during SMTP delivery.

Motivation

SMTP itself only guarantees communication between mail transfer agents.

There are several distinct milestones in message delivery:

  • Message accepted by the sender’s SMTP server.
  • Message successfully relayed to the destination MX.
  • Message accepted into the destination server’s local mail queue.
  • Message delivered into the recipient’s mailbox.
  • Message read by the recipient.

Today, Stalwart already reports failures and delays.

However, there is currently no mechanism to positively notify the sender when one of the earlier delivery milestones has been reached.

Proposed Behaviour

The feature should only activate when the sender explicitly requests delivery notifications.

This could be triggered by:

  • SMTP DSN request (NOTIFY=SUCCESS)
  • JMAP/Submission equivalent
  • Future API support

If no delivery notification was requested, Stalwart would behave exactly as it does today.

Local Delivery Notifications

Rather than waiting for an RFC 3461 DSN from the remote server, Stalwart should generate a local informational notification whenever one of the following events occurs.

Level 1 — Successfully Relayed

When Stalwart receives a successful final SMTP response (normally 250 after DATA), generate:

Delivery Notification

Your message has been successfully accepted by the destination mail server.

Include:

  • sender
  • recipient
  • Message-ID
  • Date
  • Remote MX hostname
  • Remote IP
  • SMTP response
  • Queue ID (if provided)
  • TLS protocol
  • TLS cipher
  • Delivery duration

Example:

Delivery Notification

Your message has been successfully accepted by:

mx2.example.com

Recipient:
[email protected]

SMTP Response:
250 2.0.0 OK queued as 6D31B2A8

TLS:
TLS 1.3
TLS_AES_256_GCM_SHA384

Elapsed Time:
0.41 seconds

This information is already known by Stalwart.

No SMTP standards are violated because this is purely a locally generated informational message.

Level 2 — Remote DSN Received

If the destination server later returns an RFC 3461 success DSN, generate a second notification.

Example:

Delivery Notification

The destination mail server has confirmed successful delivery.

Recipient:
[email protected]

Status:
Delivered

Remote Diagnostic:
Delivered to recipient mailbox

This distinguishes between:

  • accepted by destination server
  • confirmed delivered by destination server

Level 3 — Failure

Stalwart already generates these.

No change required.

Why this is useful

This provides immediate confirmation that:

  • DNS lookup succeeded
  • TLS negotiation succeeded
  • SMTP transaction completed
  • destination server accepted responsibility

For many users, this is the most useful piece of information.

Without it, there is no indication whether the message left the sender’s server unless they inspect logs.

Why this is not an RFC 3461 replacement

This proposal does not ask Stalwart to claim mailbox delivery.

Instead, it reports only facts that Stalwart personally observed.

For example:

✔ Correct

Destination server accepted the message.

✔ Correct

Remote server responded:
250 2.0.0 OK queued as ...

✘ Never generated

Recipient has read the message.

✘ Never generated

Message was delivered to Inbox.

Unless an actual RFC 3461 DSN later confirms those facts.

Configuration

Suggested new option:

[mta.delivery_notifications]

enabled = true

mode = "requested"

Possible values:

disabled
requested
always

Where:

disabled

Current behaviour.

requested

Generate notifications only when the sender requested delivery notifications.

(Default recommendation.)

always

Always generate notifications regardless of sender request.

Useful for administrators.

Notification Types

Possible notification categories:

  • Accepted by remote MX
  • Deferred
  • Retrying
  • Delivered (remote DSN)
  • Failed
  • Expired

User Experience

Instead of requiring users to examine logs, they receive concise, human-readable status messages.

For example:

Subject:
Delivery Notification

Status:
Accepted by destination mail server

Recipient:
[email protected]

Remote Server:
mx2.example.com

SMTP Response:
250 2.0.0 queued as 481F6E

TLS:
TLS 1.3

Elapsed:
0.38 seconds

This is especially valuable when communicating with external organizations, where “accepted by the destination server” is often sufficient to demonstrate successful transmission.

Why This Fits Stalwart

Stalwart already maintains the information required to generate these notifications:

  • outbound queue
  • SMTP transaction state
  • remote responses
  • TLS session information
  • DSN processing
  • authenticated sender identity

This proposal simply exposes that information to users in a structured, optional manner.

Benefits

  • Familiar functionality for administrators migrating from groupware products.
  • Improves user confidence that messages have successfully left their server.
  • Requires no changes to SMTP standards.
  • Does not fabricate delivery information.
  • Fully backwards compatible.
  • Disabled by default if desired.
  • Complements, rather than replaces, RFC 3461 DSNs.