When (as root) I use -C to run Exim with an alternate configuration file, it gives an error about being unable to create a spool file when trying to run an autoreply transport. Why is this?

When Exim is called with -C, it passes on -C to any instances of itself that it calls (so that the whole sequence uses the same config file). If it's running as exim when it does this, all is well. However, if it happens as a consequence of a non-privileged user running autoreply, the called Exim gives up its root privilege. Then it can't write to the spool. This means that you can't use -C (even as root) to run an instance of Exim that is going to try to run autoreply from a process that is neither root nor exim. Because of the architecture of Exim (using re-execs to regain privilege), there isn't any way round this restriction. Therefore, the only way you can make this scenario work is to run the autoreply transport as exim (that is, the user that owns the Exim spool files). This may be satisfactory for autoreplies that are essentially system-generated, but of course is no good for autoreplies from unprivileged users, where you want the autoreply transport to be run as the user. To get that to work with an alternate configuration, you'll have to use two Exim binaries, with different configuration file names in each. See S001 for a script that patches the configuration name in an Exim binary.