In an ideal world, we should be able to put a web proxy login page in front of SmarterMail.   This would allow the web proxy to grant different features to different users, while preventing a whole host of attacks from unauthenticated attackers.   It would also provide an additional tool for detecting attack sources.   I have tried to implement this design with both SmarterMail and with other products, and the attempt has consistently failed.

The root of this problem becomes evident from using the SmarterMail API.  An authentication token is passed as an http header parameter {'Authorization': value}, and a submission is expected to have only one Authorization header.   So if the authorization value is the one expected by SmarterMail, then the web proxy reject the packet, and if the authorization value is the one expected by the web proxy, SmarterMail will reject the packet.   My tested web proxy was able to support backend authentication if the backend server would accept Basic Authentication.  In that mode, the web proxy would remember the user's credentials and relay them to the backend server.  But most applications that we use, including SmarterMail, so not rely on Basic Authentication because that user interface is terrible.

An ideal web proxy would be able to allow the user to login manually to the backend system, then cache the authentication token returned by the backend application.   I don't know if such a product exists.