Due to a long-standing bug in AppleScript and macOS Mail, you can't send HTML format emails: The applescript tell theMessage to set html content to "<html>..."
has not worked in recent versions of Mail.app for several years.
I found a clever workaround: if you create a WebViewer and load your HTML content using a "data:text/html..." URL, you can then click to select the WebViewer, and use Edit / Select All. This will copy the HTML to the clipboard, after which you can paste it into a new email message in Mail.app. Works great.
However, I can't seem to find a way to script this inside FileMaker script steps:
Go To Object "WebViewer1"
Select All
Copy
does not work, failing with Error [3] Command is not availble...
It is possible to do it using AppleScript and System Events sending the Command-A (Select all) and Command-C (Edit/Copy) keystrokes, but this solution is brittle, and will fail if the user changes the active window.
Question: is there any way to script these steps? (Click to select web viewer, select all, copy) inside FileMaker itself? I'm OK using MBS plugins if that helps.
Not sure if you would consider this option, but you could also use an email API and connect that to FileMaker via INSERT FROM URL. Then, you could send any email format you want.
Right - in fact that's how I used to do it: I would send emails directly via SMTP (using Curl). Sadly, the organization I'm using went to an extremely strict 2FA system, and refuses to allow either OAuth or app-specific passwords, so the only way I can send emails now is from a mail client.
I vaguely recall when we lost the ability to set HTML content in a new Mail message via AppleScript.
Feels like around 5-6 years ago. At the time, I maintained a solution that was using that technique. At that time, I did some research and found that it was still possible to script a new Mail message to use rich text content and images. This was not as powerful as using HTML, but it still did allow for setting fonts, font-sizes, colors, and (I believe) basic image insertion.
That solution since left behind the AppleScript/Mail approach, which feels like the right thing, but I still have some code I could share with you if you are interested in playing around with the rich text idea. It never made it into production, so I can't offer any guarantees about having caught and fixed all the gotchas, but I just took a look, and I can see that I tried to make it very simple to integrate. Just tried it with a sample message right now, and it seems to do what is expected.
All that said (and please forgive me if I am preaching to the choir), I think you will be best off when you can leave the AppleScript approach behind.
Steve, does the "rich text" support table styles? The reason I'm using HTML is the need to present a fairly complex table of data.
Another idea would be to save the HTML as PDF, then include the PDF as an attachment to a plain text email. I don't like this solution quite as much, since it often requires the end user to take another action to view the PDF content.
No table styles, unfortunately. Just things like font and color (and size) of the text. I don't think that it would be any help at all for rendering a table.
Thanks for the help everyone. This feels like a very 2020s story - something which should be simple is very very difficult due to an overlapping set of bugs and overly restrictive security issues.
I had a perfectly usable system, sending plain text emails from FileMaker using Curl and a secondary ISP account (basicaly spoofing the "From" address). This worked fine for years.
A couple of years ago, Mail providers such as GMail started tightening up rules, so spoofed email wouldn't be delivered regularly. (Similar issues happened to mailling lists, due to SPF/DMARC rules).
So I started sending mail using FileMaker/Curl direct to the proper SMTP server.
This worked great for a couple of years, but then the agency decided to move to 2FA and blocked external SMTP access.
I went back to sending plain Text emails from Mail.app using AppleScripting via FileMaker. This worked fine for a while.
But then I needed to start sending HTML emails (with tables), and I ran into this mysterious applescript / HTML mail bug. And here we are...
Just because I'd like to make sure I am understanding correctly:
The 2FA still applies when sending the email via Mail.app, but it's just that it's not a blocker in that scenario because there is a human who is actually navigating the 2FA piece when the email is sent via Mail.app ?
Good question! The system is an Exchange (Office 365?) server, and used to allow plain SMTP access. During COVID, there was a "big hack" and the agency decided to force everyone into using 2FA with the Duo Authenticator.
My understanding (which may be wrong) is that this uses OAuth under the hood, and Mail.app has support for it, so it all "just works".
After the change, I had to re-enter my password within Mail.app, and at some point it popped open a new window, which looked like a WebKit viewer, which navigated to my agency's site, and (after a few steps) eventually the 2FA was triggered, and I authenticated via my iPhone, and after that point Mail.app worked fine with the Exchange server.
I did some research...
The common solution for this is to enable "App-specific passwords" so that "dumb" SMTP apps can retain access. Unfortunately, although Exchange and Office 365 supports this, my agency has not enabled this feature.
There are some FileMaker plugins which claim to support OAuth2 (such as the Mail.it plugin from Dacons.net) but it did not seem like this was a viable solution. When I looked into it, the documentation seemed to suggest that to use OAuth2 from a third-party plugin, still required the mail administrators to set up permissions to do so. I would love to be proven wrong on this!
There are ongoing security problems with Exchange Server. The first reports were made public in December 2020. Here we are in September 2021. Last patch tuesday MS released the latest in a series of patches to handle this. Unfortunately, in some cases it prevents anyone on the network from using printers, so the problem hasn't been resolved after 9 months and counting.