MarcDolley

Send Email Security Concerns

Discussion created by MarcDolley on Jan 14, 2019
Latest reply on Jan 16, 2019 by MarcDolley

First, a bit of background. One of my long term clients had their email hacked. It had nothing to do with FileMaker. They switched to an Office365 setup and got hacked again. Also not FileMaker related. As a result of multiple hacks, they hired an IT company to ensure it couldn’t happen again. Multiple levels of security were added including anti-virus, anti-malware and pretty much anti-everything software. All of the desktop computers now run terminal server. They also implemented their own Microsoft Exchange server. In the process, they neglected to mention it to me, so suddenly, none of the scripted emails from their FileMaker solution were being sent. Of course this happened a few days before the Christmas break.

After identifying the issue, we updated the email settings and everything was fine (sort of). Part of the strategy was to use PSOS to send emails from iPad’s and iPhone’s running FM Go out in the field. Most of the emails sent from the field were internal emails with fixed content, so I was able to bundle all of the data into a multi-value variable and pass it to the server as a script parameter. As most would probably already know, when PSOS is run, it has no context, so doing it this way doesn’t rely on re-establishing context to send the email. There were a couple of glitches in the process which I overcame. The one email which was more difficult was sending delivery dockets. This process required the generation and attachment of a PDF to the email. I successfully managed to get that working, despite it being a lot more complicated than sending direct from FMPA.

All other emails get sent from desktop computers (Mac and Windows) from within the office via terminal server. That meant minimal changes to the scripts to get them working. That was all fine until we discovered that some emails weren’t getting through to customers. In one example, about 20 out of 500 emails weren’t received. We spent hours trying to find a cause until we eventually eliminated FileMaker as being the source of the problem. That’s when everything went pear-shaped. Despite being given the correct settings by the IT person, he neglected to tell us that this was only a temporary workaround and he had now switched off access to port 25 on the terminal server so now no emails were going out (even though there were no error messages in FMPA or FMS). He insisted that ALL emails had to be sent via the server (using PSOS). Bear in mind, this person knows nothing about FileMaker. The basis for his argument is that having port 25 open is a massive security risk and could well result in further hacks.

Our response was that while this was true, the simplest solution was to open port 25 just to the FileMaker Pro application (FMPA to be precise). This would allow users to continue to send emails from FileMaker without compromising the gross-overkill security measure he has put in place. The only thing allowed to send data to port 25 on the exchange server would be the FileMaker Pro Advanced application. In order for it to be compromised, someone would have to hack into their FileMaker solution with full access and be sufficiently competent in scripting to be able to send out emails. That seems pretty unlikely (to both us and the client). He seems perfectly okay with opening port 25 to the computer running FM Server, he just doesn’t want the users to be able to access it.

The alternative is to re-write every single one of the email scripts (100 plus) to use PSOS. Some of them will be quite complex. For example, their invoicing process involves generating a PDF which gets saved with the invoice record before being emailed to the client. Invoices currently get sent in a batch (found set) and there can be as many as 500 sent in one go via a looping script. Saving the PDF in the record allows the client to access and download copies of each invoice via a WebDirect client portal. Using PSOS, it will still have to do that as well as re-generating the PDF on the server and emailing it. This also means the PDF’s will build up in the documents folder on the server and will periodically need to be cleared out. The re-write will be time-consuming and expensive for the client and, as far as we’re concerned, unnecessary. It will also place a substantial load on the server which could impact other users (as opposed to just the user running it).

I’d be interested to hear from others who may have encountered similar issues and how they resolved them. I’d also like to know whether the method we proposed is sufficiently secure or whether there are other methods we can employ which will enable email functionality without compromising security (are you there Mr. Blackwell?). It seems the IT person refuses to budge on his stance and the client isn’t happy about the perceived unnecessary expense of a re-write.

Marc

Outcomes