Operate chasquid aliases and filtering hooks safely

chasquid exposes aliases and hooks for integration with filtering, DKIM/DMARC tooling, and local delivery. These are server-side integration points, not a promise of a built-in durable JSON webhook product.

Bound the extension

1. Review the current hook/alias documentation linked from the official project site.
2. Define the exact recipient/address expansion required, including plus/suffix handling and any forwarding destinations.
3. Run hook processes under the documented restricted service identity, with bounded runtime and output size.
4. Define temporary/permanent failure handling according to the actual hook contract. Do not return success before required durable work exists.

Keep untrusted sender/body values out of shell command construction. A filtering hook should not gain account-management or arbitrary outbound-send credentials just because it can inspect a message.

Exercise recovery before public traffic

Test an allowed alias, an unknown alias, a hook timeout, malformed message content, and a temporary downstream failure with controlled mail. Check the queue/log outcome rather than only the hook’s console output.

If forwarding to an application receiving provider such as MailKite, use an approved exact destination and prevent forwarding loops; the provider independently authenticates its later webhook. A direct HTTP handoff needs your own verified transport, retries, retention, and deduplication design. Do not claim those properties emerge automatically from an alias or script exit code.