I’m curious as to what people are doing about the move away from allowing 3rd party software using username and password authentication, particularly for SMTP.
Both Microsoft and Google are in the process of removing basic authentication and enforcing OAuth 2.0. We’ve just spent the last 6 weeks rewriting the email module in our SaleFaith CRM to authenticate and utilise OAuth.
I expected there to be more discussion about this, particularly as the original Microsoft deadline was 1st October, which has subsequently been delayed to 1st January.
If you use SMTP with "SMTP auth" on 365, you're OK according to MS.
If you use 2FA + app password with 365, you're OK, again, according to MS.
I'm sticking with SMTP + strong passwords and these approaches for 365.
For me, the cure (oauth2) is worse than the disease (SMTP). It's all good. MS has no plans to get rid of SMTP support.
--
With DropBox, the situation is similar, but I figured out how to use their API using a long expiration period so it's just like it was before. It works every time with no authentication needed.
If you use SMTP AUTH, the "basic authentication" issue doesn't apply. The MS document says that (as I wrote above). Same goes for 2FA + App password. MS confirmed both of these for me recently.
If you're using just user name + password, then, yes, that is going bye-bye.
But these other two options are safe and I've been ASSURED by MS that they're not going anywhere.
OAUTH2 is such a major PIA. I've implemented it as a test, and, sure, it works, but the manual token step is too intrusive. No Thanks!
If I need email security, I've already implemented RSA (PGP type) email. That plus strong passwords to begin with make me confident.
We’ve gone all in with OAuth for our email within FileMaker, having all the setup within our MailIt based email system.
I hope you’re right with the information you’ve received, I’m always skeptical when reading phrases such as:
Therefore, we highly recommend that you disable SMTP AUTH in your Exchange Online organization, and enable it only for the accounts (that is, mailboxes) that still require it.
Passkeys slightly worry me. SSL/TLS implementations for servers have the private key on a physically secure device and the networking can be locked down as required; a breach can nevertheless affect hundreds of thousands, even millions, of users.
Passkeys are on a mobile device that is admittedly normally kept under tight control and the biometric security is great; still, if the private keys on that device are compromised the effect is TOTAL - every service for that user is now vulnerable.
Rationally, I know that on balance the change to the security landscape is beneficial for everyone, but the cynic in me can't help but observe that the service providers will be much less vulnerable and the end users will be carrying a slightly higher risk.
With my current gig in the clinical health world, email is a source of frustration. Overall I'm glad that the changes are coming but really it's the content of the messages over the global network that need protecting - securing the originating and destination mail servers is a good step but until every server in the chain is under control the chance of information leakage remains.
For our large organisation I'm considering moving a lot of the notifications I send to MS Teams, which means integrating with the Graph API and thus probably other benefits. Any detailed messages can then be shared as an SSL-protected URL that's managed by our WebDirect implementation.
Early days, but the urgency on this has been raised given the push from Google and MS.
I contacted MS several times to clarify their intentions. I'm totally satisfied.
One serious problem is that the FileMaker SMTP client is so far behind the times (ancient), it should be embarrassing to Claris. But, rather than updating it (and lots else in FileMaker), they're forging ahead with initiatives (presumably since that may be where they think the money is ...) that I neither want nor need.
Yup, agreed. We also try to avoid 3rd party APIs as we don’t like our systems having elements that are outside of our control. Neither do we use many plugins, but have standardised on Dacons MailIt, as we’ve always had good support and communication with them.
There is so much of FileMaker that, to quote my wife (and codirector), ‘nearly works’. And don’t even get me going on the missing ‘OnRecordExit’ or ‘OnRecordUnload’ script trigger. This causes us hours trying to get around it.
I use a library and a REST approach. Has worked perfectly for years (still does both with SMTP AUTH and with 2FA + app password). This approach is totally free and does not rely on a third-party company (but does require a little coding).
I've never relied on FileMaker to do email -- since they didn't support multiple attachments until only relatively recently. Still no SMTP auth. FileMaker's SMTP email is soon to be non-usable with 365 and possibly others (come on Claris! Just add SMTP AUTH!!!!).
There is no right or wrong on this one, it is purely down to personal preference as the required features are not natively within FileMaker.
We have developer licenses for our CRM based products, hence it makes sense to use them and have been for a long time - we obtain many other benefits from these. Christian’s MBS plugin is excellent and if we were starting now, would probably have chosen that.
Claris are pushing APIs and that’s fine, as is any other system that works - free or otherwise.
I use SendGrid API to send Emails via REST. You need to set up DNS entries properly, but it works with "Insert from URL". Amazon's Simple Email Service works the same way too. But I have a FileMaker template that works with SendGrid already set up at https://tms.us/FM to send emails. These services are primarily designed for mass emailing, but they also work for individual emails. I use them to send HTML email too since FileMaker's Send Mail doesn't support it. These services do cost. If you have an extra Linux box or instance, you might put JavaMail on it and run your own mail server like OliverBarrett suggested.
