phpBB extensions can modify message headers through the core.modify_email_headers event, but they cannot reliably modify the RFC 5321 envelope sender used by the mail transport.

Adding or changing a Return-Path header is not sufficient. The actual return path is derived from the SMTP MAIL FROM command, or from the equivalent sender argument used by the local mail transport, and receiving mail servers may replace the header.

This prevents extensions from implementing features such as Variable Envelope Return Path (VERP), where delivery status notifications must be routed to a message-specific bounce address.

A new core event named core.modify_email_envelope_sender is proposed.
It should be dispatched after the message and its final headers have been prepared, but before the message is sent or added to the queue.

The event should expose:

• envelope_sender: a mutable envelope sender initialized with board_email;
• the prepared message or headers, so an extension can keep any visible Return-Path information consistent with the selected envelope sender.

The selected envelope sender must be preserved in queued messages and used by
all supported mail transports.

For security, phpBB should:

• reject values containing CR or LF;
• require a valid single email address;
• fall back to board_email when the supplied value is invalid;
• validate queued values again before sending.

The default behavior must remain unchanged when no listener modifies the envelope sender, and queue entries created before the new field was introduced must remain  compatible.

The primary use case is a bounce-handling extension that adds an opaque per-message correlation identifier to the SMTP envelope sender. This allows delivery reports to remain correlated even when a mail provider removes custom message headers.

This proposal only concerns one envelope sender per message. Per-recipient delivery splitting is outside the scope of this request.