Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Is that still needed if you use Mail Privacy Protection?

Edit: On the GitHub page of MailTrackerBlocker it says:
Yeah, you'd think Mail Privacy Protection would be better. But in reality, very often I've had Mail throw up the alert that it's "unable to load remote content privately"* The only option shown at that point is to load the images anyway, which means loading the trackers too.

MailTrackerBlocker, on the other hand, just quietly works and has a little badge that shows you if trackers were found or not, and if so which were blocked (which is also good information to have). Funny to me that the developer posted that and yet keeps updating the plugin. He also mentions in the GitHub discussions that he's looking into MailKit, so hopefully it'll get updated to work.

* Here's Apple's support article about it. I'm not using a VPN but I've still gotten this error many times.
 
Last edited:
I have been a SpamSieve beta tester now since 2002 and I think it could be described as a mature app that just works reliably year after year.

I hope this change will allow it roll on reliably for another 20+ years and it is not often you can say that about an app.
 
  • Like
Reactions: Chuckeee
These changes are engineered to give consumers more privacy and security over their invaluable email communications. Only Apple can do this.
Not really — at least not in this case.

Mail plug-ins were so convoluted to install and maintain that most average users would never have bothered. Even on this thread, many didn't know the capability even existed, much less how to use it. From the beginning, Mail plug-ins/bundles were more of a power-user tool; IIRC, the capability first showed up in 2004 when Apple introduced a massive update to the Mail app in OS X Tiger, and it's been just sort of kicking around ever since.

However, the problem is that Apple never "officially" supported these plug-ins. The Mac was in a different place back then — everything was more grassroots in those days — and Apple's developers were happy to provide a plug-in architecture for hobbyists to play around with at their own risk. If your plug-in broke something, that was on you, and Apple never guaranteed that its code for these plug-ins would remain consistent — if Apple broke something in a Mail update, it was the responsibility of the developer to figure out what had changed and fix their plug-in, with no official help from Apple.

In fact, the risk of things breaking was so high that Apple coded in a "compatibility UUID" in Mail, changing it with each update. At the very least, plug-ins had to be updated with the new UUID for each new version of Mail; Mail would refuse to load any plug-ins that didn't have a matching UUID.

For simpler plug-ins like Gmailinator, it was usually enough to just dig out the new UUID from Mail.app's Info.plist file and paste it into Gmailinator's. The code-signing requirements in more recent versions of macOS made this a bit more complicated, but it was still doable. I usually just rebuilt from source in Xcode with each new macOS point release and dropped in the newly-compiled bundle with the proper UUID. Actual code changes were usually unnecessary as Gmailinator didn't do much other than remap a few keys.

More complicated plug-ins like Smallcubed's Mailsuite were also usually fine with minor point releases, and the developers typically pushed out the necessary versions quickly enough to ensure the UUIDs matched. Major macOS releases required bigger changes, which was why Smallcubed eventually began selling paid upgrades and maintenance plans as they had to put actual work into it, and it wasn't as simple as following Apple's documentation on what had changed because there wasn't any. Instead, they had to figure it out for themselves.

So, all that having been said, Apple's motivation for removing this is most likely some software engineer who has become exhausted with maintaining a massive chunk of legacy code that's nearly 20 years old. They've likely been keeping it together with bandaids and bailing-wire for years, as it was never an official feature of Mail in the first place. Who knows, maybe the folks who originally built it, maintained it, and championed it aren't even at Apple anymore.

On the flip side, removing the plug-in capability will also encourage developers who can use the new MailKit extensions to get with the program and rebuild them for the new features. They've had two years to do this, but it's a lot of work, so staying with the plug-in model has just been way easier. It seems some will be able to move to extensions, but sadly the limited MailKit frameworks will be leaving a lot of other great ones behind.
 
Just what the world desperately needs... another email client. Hopefully it won't use a subscription business model
I think it's almost guaranteed that it MailMaven will use a subscription model — or at least a hybrid model of sorts. SmallCubed sold an annual maintenance plan for its Mailsuite tools that were merely plug-ins for Mail. Granted, updating those each year was a fair amount of work, but I can't imagine that's more work than building an entire email app.

It already says on their website that "An active Maintenance Plan for MailSuite will also work with MailMaven. and locks-in preferential pricing for MailMaven for as long as your Maintenance Plan remains active."
 
  • Like
Reactions: CTinCT and wanha
I wish Apple mail just added some keyboard functionality to quickly file emails to different mail folders.
This.

I used both Mail Act-On (MAO) and Gmailinator for exactly this purpose. Mail Act-On was a bit better at it, but I like to play with macOS betas. MAO wouldn't typically get updated after macOS was released. Gmailinator I could compile from code, and since it used Gmail shortcuts, there was a piece that mapped the "L" button to bring up a list of folders, just like you'd get using Gmail on the web (I changed it to "V" as it's a "move" rather than "label" but same difference).

One nice bonus of having a TouchBar on my MBP is that I at least get a prompt for filing e-mails into known folders. Mail is pretty clever about figuring out where messages should go. For instance, I have a "Receipts" folder, and generally when I get a receipt for something, it knows I want to put it there, so it will put that up as the "Move to" button on my TouchBar. It's the same as what you get if you add the "Move to" button to your toolbar, but it's more easily within reach.

There's also a keyboard shortcut for this (CTRL+CMD+M), but the TouchBar is nicer because it's a single tap, and you can see which folder Mail thinks it should go into. With the keyboard shortcut you're kind of flying blind unless you put the "Move to" button in the toolbar and take a look at that first.

While that's obviously not nearly as good as being able to pick any folder arbitrarily from the keyboard, it does help a lot with my regular filing of things since about 80% of what I receive goes into predictable folders (e.g., receipts, newsletters, personal emails from family, etc).
 
Thank you so much for sharing this! It would be devastating to lose SpamSieve. I will happily repurchase the new 3.0 version!

I’ve got the 2020 iMac so I’m not completely cut off yet, but I know it’s right around the corner. On the fence whether I should upgrade to a Studio Display + Studio (or mini) or wait it out for M3/M4. Tough call, I keep going back and forth.
The 2017 iMac is pretty slow for my use anyway. In April, I added a headless Mac mini M2 Pro to handle the applications that need to run 24/7 (Roon Core, WeatherCat, Plex Server, Security Spy.) Then in January/February, I'll replace the iMac with the MBP and a monitor. So it will be both my laptop and my desktop, while the mini handles server stuff.
 
Apple loves doing this kind of thing -- see how they ruined Safari extensions -- and then they wonder why their native apps' usage stagnates rather than grows.
While I agree that limiting the new API isn’t great, I don’t think Safari is a good example. Safari used to have very little in the way of good extension options and there are a lot more in recent years, partially because of interoperability between iOS and macOS safari extensions.
 
And you can only blame the bad actors for this, not Apple.
Regardless of who to be blamed, the trend will be a version of macOS locked down just as hard as iOS, regardless of what comment Craig may or may not put up.
 
For instance, one of the handiest mail plug-ins was Gmailinator, which mapped the Gmail keyboard shortcuts (e.g. j, k, shift-#, etc) to Apple Mail. It was a grassroots open-source project on Github that was maintained and forked by several folks over the years but somehow kept on ticking. Sadly, that kind of functionality isn't possible with the new Mail Extensions, and it's such a jarring shift to have to return to arrow-key navigation that I may be done with Apple Mail on the Mac.

Does the extension platform not allow any gmail style keyboard shortcuts? I did come across Gmailinator but now it sounds like I shouldn't bother if it is about to be obsolete.

I just want to be able to move emails by hitting a key (v), typing a folder name, and hitting enter!
 
Does the extension platform not allow any gmail style keyboard shortcuts? I did come across Gmailinator but now it sounds like I shouldn't bother if it is about to be obsolete.
Sadly, from everything I can glean from the MailKit developer docs, the answer would seem to be no. Certainly not for the broad kind of remapping that Gmailinator was capable of. The biggest challenge is getting unmodified keys (e.g., j, k, v, etc, without a CTRL/CMD/OPT) to only work in the message list without impacting the ability to actually type those letters when writing an email or performing a search. Gmailinator handled this brilliantly well, but it's not the sort of thing that's going to be exposed by the MailKit frameworks.

I toyed with the idea of using Karabiner Elements to replicate some of that functionality, but the best I could do was to map to OPT-J/K, as otherwise, the J and K keys couldn't be typed. There's also no realistic way to map anything to an easy "move" command, as Apple Mail simply doesn't have a dialog box for this — that was custom code in Gmailinator.

I just want to be able to move emails by hitting a key (v), typing a folder name, and hitting enter!
The one piece of good news is that there could be a way for an enterprising developer to cook up something that could do this, but it wouldn't be a MailKit extension. Ironically, it should be doable in AppleScript, as Mail still has a pretty rich AppleScript dictionary, including the ability to get a list of folders ("mailboxes" in Apple Mail parlance) and move selected messages into other mailboxes. You'd have to map the AppleScript to a keyboard sequence using some other tool like Fastscripts or Keyboard Maestro, and of course, you couldn't just use "v" — it would have to be something like OPT-V or CTRL-V.

Here's a quick'n'dirty script I cobbled together just now as a sort of mental exercise... it seems to get the job done for me in the current macOS Sonoma beta. Be sure to replace "my account name" with whatever your IMAP account is called.

AppleScript:
tell application "Mail"
   
    set myaccount to "my account name"  
    set folderlist to name of mailboxes in account myaccount  
    set targetfolder to choose from list of folderlist  
    set theMessages to selection
   
    repeat with eachMessage in theMessages
        set mailbox of eachMessage to mailbox (targetfolder as string) of account myaccount  
    end repeat
   
end tell
 
Sadly, from everything I can glean from the MailKit developer docs, the answer would seem to be no. Certainly not for the broad kind of remapping that Gmailinator was capable of. The biggest challenge is getting unmodified keys (e.g., j, k, v, etc, without a CTRL/CMD/OPT) to only work in the message list without impacting the ability to actually type those letters when writing an email or performing a search. Gmailinator handled this brilliantly well, but it's not the sort of thing that's going to be exposed by the MailKit frameworks.

I toyed with the idea of using Karabiner Elements to replicate some of that functionality, but the best I could do was to map to OPT-J/K, as otherwise, the J and K keys couldn't be typed. There's also no realistic way to map anything to an easy "move" command, as Apple Mail simply doesn't have a dialog box for this — that was custom code in Gmailinator.


The one piece of good news is that there could be a way for an enterprising developer to cook up something that could do this, but it wouldn't be a MailKit extension. Ironically, it should be doable in AppleScript, as Mail still has a pretty rich AppleScript dictionary, including the ability to get a list of folders ("mailboxes" in Apple Mail parlance) and move selected messages into other mailboxes. You'd have to map the AppleScript to a keyboard sequence using some other tool like Fastscripts or Keyboard Maestro, and of course, you couldn't just use "v" — it would have to be something like OPT-V or CTRL-V.

Here's a quick'n'dirty script I cobbled together just now as a sort of mental exercise... it seems to get the job done for me in the current macOS Sonoma beta. Be sure to replace "my account name" with whatever your IMAP account is called.

AppleScript:
tell application "Mail"
  
    set myaccount to "my account name" 
    set folderlist to name of mailboxes in account myaccount 
    set targetfolder to choose from list of folderlist 
    set theMessages to selection
  
    repeat with eachMessage in theMessages
        set mailbox of eachMessage to mailbox (targetfolder as string) of account myaccount 
    end repeat
  
end tell

Wow, thank you for the well thought out reply. I'm definitely going to give this a try (while also continuing with the apple.com/feedback submissions for better keyboard shortcut support)!
 
...

So, all that having been said, Apple's motivation for removing this is most likely some software engineer who has become exhausted with maintaining a massive chunk of legacy code that's nearly 20 years old. They've likely been keeping it together with bandaids and bailing-wire for years, as it was never an official feature of Mail in the first place. Who knows, maybe the folks who originally built it, maintained it, and championed it aren't even at Apple anymore.

On the flip side, removing the plug-in capability will also encourage developers who can use the new MailKit extensions to get with the program and rebuild them for the new features. They've had two years to do this, but it's a lot of work, so staying with the plug-in model has just been way easier. It seems some will be able to move to extensions, but sadly the limited MailKit frameworks will be leaving a lot of other great ones behind.

Apple's removing it because some developers found a way of side loading apps onto the phone through plug-ins. Instead of fixing plug-ins to prevent this, they're just removing mail plug-ins.
 
Apple's removing it because some developers found a way of side loading apps onto the phone through plug-ins. Instead of fixing plug-ins to prevent this, they're just removing mail plug-ins.
I don’t imagine sideloading would have anything to do with this as we’re talking about a Mac feature. The iPhone and iPad have never supported Mail plug-ins (sadly), and running Mail plug-ins in the macOS Mail app has no effect on the iPhone or iPad Mail apps.

Mail plug-ins are a legacy feature that was never officially supported or properly documented. Support has been dropped now in favour of Mail Extensions, which use more stable APIs but are also considerably more limited as to what they can do.
 
  • Like
Reactions: gwhizkids
Sonoma is here in a week and there are no mail plugs to have mail unread like mail act on until you mark it manually :(
Smallcubed say "Apple has permanently disabled the ability to load any Mail plugin in macOS 14."

I really like Apple mail but without this feature, i know i'll accidentally mark mail as read and miss important things. If anyone has any alternative ideas other than another mail client, i'm all ears! :)
 
Sonoma is here in a week and there are no mail plugs to have mail unread like mail act on until you mark it manually :(
Sadly, I don’t think you’re going to see one. The official MailKit extensions framework is extremely limited compared with what the old plug-ins could do.

From what I can see in Apple’s developer documentation, marking or leaving messages as unread is not one of the things that Apple allows. Message properties can only be adjusted as messages are downloaded.

I’ve had to adjust my workflow a bit in Apple Mail to account for the lack of plug-ins. One thing that could work is to use flags instead. Since Apple Mail has several different flag colors, if you set up a rule to flag important messages (or even all messages) with a specific color you don’t use for anything else, then you could rely on those. Mail on macOS and iOS lets you filter by flagged and unread, and clearing the flags when you’re done with them is also pretty easy to do.
 
  • Like
Reactions: TwoBytes
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.