OpenACS sends many kinds of mail: notifications, forum subscriptions, password resets, and administrative alerts. Recent additions to NaviServer’s nssmtpd module make the configuration of these services simpler, particularly in Docker deployments.
The changes cover both outgoing application mail and forwarding site addresses, such as webmaster@your-domain.org, to the people maintaining that site.
Previously, the openacs.org setup relied on Postfix for both alias resolution and delivery. Alias handling can now be configured directly in NaviServer, with the alias file stored alongside the OpenACS configuration. This removes the dependency on a host Postfix installation for managing aliases and avoids maintaining separate alias maps for the application and mail containers.
For example, a virtual alias file can contain:
webmaster@example.org alice@example.net, bob@example.net
Mail sent by OpenACS to webmaster@example.org is then forwarded to both maintainers. The same alias can receive mail from outside when nssmtpd is configured as the domain’s incoming SMTP endpoint. No local mailbox is required.
The new functionality includes:
- Alias resolution for incoming and outgoing mail, including multiple destinations and alias chains.
- Optional rejection of unknown incoming addresses, while retaining passthrough behavior for outgoing OpenACS mail.
- Lightweight greylisting to reduce incoming spam to public addresses such as
webmaster. Internal OpenACS submissions bypass the delay.
Greylisting is a lightweight technique for reducing incoming spam: it temporarily defers the first delivery attempt from an unfamiliar combination of sending IP address, envelope sender, and recipient. Legitimate mail servers normally retry, while some spam senders do not. It can delay legitimate mail and does not stop spam from senders that retry. See RFC 6647: Email Greylisting—An Applicability Statement for SMTP.
These features are implemented through Tcl-extensible callbacks. The supplied resolver reads standard alias files, but installations can provide their own resolver using OpenACS APIs. No additional database or spam-filtering container is required for these features.
An upstream mail relay is still responsible for reliable queued delivery and retries. The simplification is that alias management and incoming SMTP policy now live with the application configuration.
The additions are fully backward compatible with existing released configurations: all new features are disabled by default. They are currently being tested in the openacs.org Docker deployment.
Further details:
Feedback from other OpenACS installations is welcome.
-g
