makemap and newaliases should really be smtpctl subcommands

[poolpOrg]

makemap / newaliases were implemented back when OpenSMTPD didn't have a smtpctl command.

they should really be smtpctl subcommands, like mailq or hoststats, and not separate executables.

[poolpOrg]

@ericfaurot @clongeau we need to discuss this, we have already decided it was the way to go but there's some historical behaviour wrt parse.y and maps that had explicit naming (map aliases, map virtual, ...).

Sunil was willing to work on this but we need to take a few decisions first.

[dfateyev]

First, I can say I'm not against of it ;-) But just curious: why this combining all available features into one binary? Historically, the opposite strategy is more common in UNIX: splitting functionality into a set of small binaries.

[poolpOrg]

Good question :-)

First of all I'm a big fan of splitting functionality into small sets of binaries that do as less as possible and combining them, which is why smtpctl provides outputs that can easily be parsed by other tools rather than providing tons of subcommands to extract specific informations.

The problem here is that newaliases and makemap are historical commands which we ship to prevent confusing people, and these utilities assume we work the same ways as other MTA.

A long time ago, OpenSMTPD didn't have "tables", it used "maps" and these maps had hardcoded names, so your aliases map had to be named "aliases" to be taken into account. A former developer added some kludge to have the tools parse smtpd.conf to figure out what file was used by the "aliases", "virtual" and "secrets" maps, so the utilities know what to do. This caused makemap to depend on the smtpd.conf parser, as well as tons of other stuff since the parser has to know about plenty of structures, OpenSSL, etc ... so we started adding #ifdefs and hacking around to reduce the dependencies.

Then we introduced tables and we added support for referencing aliases, virtual or secrets from individual rules, this means that you can have as many aliases databases as you want, as many virtual as you want and they can be named however you want. The whole kludge to find which files to rebuild becomes moot as the tables are no longer necessarily named the way you'd assume, you can observe the effect of this by naming your aliases table "foobar", if you call newaliases you essentially do a no-op.

So at this point, either we decide to add more and more kludge and dependencies to newaliases and change it's behaviour to know what aliases database to rebuild, which would effectively mean our newaliases is no longer working the historical way ... or we implement it as a subcommand of smtpctl which already has this dependencies, encourage people to use the smtpctl utility rather than the historical tools and provide a historical interface with the shortcomings that we already have.

[poolpOrg]

far from being a priority anymore, we won't work on that for the foreseeable future, I'll reopen when it annoys me enough.