FAQ: Security

A security FAQ seems odd when there appears to be no security whatsoever!

Right, so let me explain.

The goal of psmtp is to provide a tool for testing apps that send email. It's expected that deployments of psmtp will be done inside a controlled (testing or QA) environment. No one should ever launch psmtp on an internet facing host, period. You'd be crazy to do it. Not just because of the lack of security, but because it just doesn't make sense.

The lack of security isn't really an oversight, but rather a deliberate feature. Again, this is a testing tool to be deployed within a testing environment to help with testing your application. The last thing you want or need is your tests failing because your dummy smtp server is refusing connections either on the smtp side or the REST side. No one needs that headache, especially when doing final regression testing just before the big release that is already 3 weeks behind schedule.

A testing tool should aid in your testing, not hinder it. Therefore everything is wide open and there are no plans to change that.

The only bit of security you will find in psmtp is the "protection" of the config settings page. I quote that because the basic authentication security in place is there more as a precaution than it is to actually secure anything. And even the basic authentication on that page is subject to removal if I find it is becoming too much of a hindrance to my test productivity.

The motivation behind me writing psmtp is that I needed a tool that allowed me to capture outgoing mail from the apps I am testing and provide a clean, flexible, and rich filtering api to find the messages of interest and easily download those messages for validation within my test case scripts. I don't have a need to test things like SMTP authentication or SMTP over SSL, etc. That's not what this is for (today). With that said, the underlying smtp library I'm using to implement the smtp server does indeed support all of these extra features, it's just I don't need them today and they would only serve as a possible hindrance on the testing that I'm currently doing. There might come a day when I need to test these kinds of things and if that day comes then I might support said features. Until then, don't expect them or, even better, provide me a patch via a pull request. ;)

As for securing the REST API, again, it's just an unnecessary layer of potential disaster waiting to happen. Again, you're only deploying psmtp in a test/QA environment, right? In such an environment the only bad thing that could happen is that another QA or dev person accidentally deletes all of your emails from the database. That sucks, but just rerun your tests to repopulate the data. There just shouldn't be anything worth securing or anyone to prevent from using the psmtp instance and so securing API requests is just making hitting the API more complicated than it needs to be. However, you have a little more say in this area if you feel so inclined to protect API calls. If you're deploying the war file into a container then you can rip apart the war, modify the web.xml descriptor and add whatever authentication you want to the REST API calls. I don't see the need or the benefit, but you can do it.

Bottom line, as far as security goes for psmtp there's just one simple rule to follow:

Do not deploy this application on an internet facing host, period!