Well, I have made it. Now the sending of the emails can be delegated to external programs.
The source is in the with_sendmail branch. (Later will be merged with the trunk, but some more work has to be done)
The implementation itself is in the file
The source is tested only that it works. I.e. it runs the external program and pipes the email to it.
The settings dialog (the tab Server) contains one more input field labeled Pipe the emails through:.
Put there the full path to program that will expect the email data from the STDIN. sSMTP should work if properly configured by itself.
I think this is good news!
I've updated my copy of the repository and reviewed the code, but have not assembled and tested.
I notice you provide a field (smtp_exec) to contain the path name of the executable. Does it allow for command line options? The \/usr/sbin/sendmail executable requires "-t" or "-ti" in order to accept input from stdin. There are many other options in the original sendmail, but the ssmtp version just used "-ti".
I know I am pushing you too much and for that I apologise :-)
But, I see you have implemented the sendmail piped out function as a part of the commands.asm SendActivationEmail function rather than as a generic SendPipedEmail (or some such name) function.
Reason: For a low volume forum, it would be very desirable to notify registered users by email when new posts have been written. As an example of a higher volume forum doing this, I cite the fossil-scm.org/forum where I receive 30 to 40 emails daily, telling me the contents of new posts. I suspect that is over the limit for most interested readers, but they are easy to delete. About 1 in 20 are of direct interest and I go to the forum to refresh context while reading the new post.
Such notification requires that the registered user have the option to turn it off, so a new preference is needed there. And the forum administrator will need a global flag to turn on/off the feature.