Possible future directions

Alternatives to sslserver

Opportunistic TLS encryption in acceptutils depends on UCSPI tools that offer the UCSPI-TLS interface. When I was creating acceptutils, the only ready-to-run implementation was ucspi-ssl’s sslserver. Since then, s6-networking has added s6-ucspitlsd, which works equally well with acceptutils. I’ve also requested UCSPI-TLS extensions be added to ucspi-tools.

BSD blocklist integration

authup could communicate successful and failed logins to blocklist, so sysadmins can set policy for their packet filter to block certain connections automatically.

Submission filters

qmail-qfilter-gpgsign could be a filter that connects to the current user’s gpg-agent to sign a message. I might add it to control/ofmipfilters.

Dual-purpose port 25

acceptutils could learn to cooperate with incoming SMTP on the same port. For instance, authup could perhaps be started with -- and additional arguments with which to replace itself when sent an unsupported SMTP request. Maybe something roughly like this:


exec sslserver -n 0 25 \
    env UCSPITLS=""    \
    authup smtp        \
    checkpassword      \
    checknotroot       \
    fixsmtpio          \
    ofmipd             \
    --                 \
    setuidgid qmaild   \
    fixsmtpio          \

Other SMTP changes

acceptutils could learn new ways to modify or extend qmail’s SMTP implementation. As a configurable proxy with an active maintainer, fixsmtpio is a sensible place to put new behaviors. Send me useful code that’s off by default, on when configured, and covered by automated tests, and I’ll gladly merge it and issue a new release. Some ideas: