[MlMt] MailMate passed the CASA tier 2 security assessment (hurrah?)

[Henry Seiden]

Benny,

SFAIK, my Google account is non-Workspace (I.E., free). Currently use 
the OAUTH2 settings in MM. It is working. As are Outlook/Live, Yahoo! 
Accounts both using OAUTH2. However my settings for Yahoo SMTP does not 
use OAUTH2 for some reason that I don’t know and most of the sends 
from that account are with another app (Apple Mail) which has it’s own 
“automatic” settings applied.

Given the payment requirements you outlined, I would feel OK deleting 
use of the one remaining Google account in MM, rather than pay 
additional for its use. My 2¢.

Respectfully,

Henry Seiden
- -
Techworks Pro Co.
E: info<at>techworkspro<dot>com
W: http://techworkspro.com

On 9 Apr 2025, at 9:04, Benny Kjær Nielsen wrote:

> **Note:** This email is important for all Gmail users. You should read 
> (the last part of) it before May 7, 2025.
>
> ---
>
> Hi MailMate users,
>
> as some of you might remember, MailMate went through a CASA tier 2 
> assessment last year in order to be able to continue to use OAuth 
> authentication with Gmail accounts. It was no secret that this was 
> going to be a yearly task going forward, but this year it comes with a 
> twist: It's no longer free.
>
> For my general thoughts on the subject, I strongly recommend my 
> previous email on the subject (the one I've replied to here). Here's a 
> direct [link to the 
> archive](https://lists.freron.com/mailmate/2024-June/017271.html).
>
> The most important part of this email is the last part. Skip ahead to 
> “**Gmail support in the future**” if you are short on time. The 
> rest is just me ranting in an attempt to collect my thoughts on the 
> subject.
>
> ---
> ### Pricing
>
> The assessment has to be done by a [CASA authorized 
> lab](https://appdefensealliance.dev/casa/casa-assessors) (most of them 
> do not advertise pricing). Google does have a preferred partner for 
> which they have negotiated a discount. As they write to me: “While 
> this means that you will incur a small cost, paid to an independent 
> assessor, we’ve worked hard to make sure this doesn’t pose an 
> undue burden.”
>
> This discounted pricing is publicly available 
> [here](https://casa.tacsecurity.com/site/home). At the time of writing 
> pricing is between $540 and $1800 (without the discount it's between 
> $1800 and $6300). I *think* at the highest price point it means that 
> you pay for being recertified once a year *forever*, but business-wise 
> that doesn't make much sense to me.
>
> Given that MailMate is at a crossroads where I'm waiting to see how 
> the [new pricing 
> model](https://blog.freron.com/2024/new-license-key-system/) works 
> out, I *do* mind the requirement for paying for recertifications, but 
> my main issue with CASA tier 2 for a desktop email client is that I 
> don't think it provides users with anything of real value. On the 
> contrary, I think it provides users with a false sense of security -- 
> and I end up spending both money and valuable time on this every year 
> instead of actually working on improving MailMate.
>
> ---
> ### Assessment/Certification
>
> I wrote about what this actually means in the email from [last 
> year](https://lists.freron.com/mailmate/2024-June/017271.html), but I 
> would like to emphasize the following point.
>
> There’s no way of knowing if MailMate will pass the assessment this 
> year or in future years -- and it might not really be possible to do 
> anything about it. MailMate is a very complex application with a lot 
> of third party dependencies. For example, it might be decided that 
> MailMate is using a framework which is no longer considered 
> sufficiently secure for Gmail access, but it’s needed to support 
> older macOS releases. They might decide that one cannot use any 
> programming languages for which there does not exist a code scanner 
> which can find vulnerabilities. Also, the process includes a self-scan 
> of the source code, but the method used for this last year seems to be 
> [deprecated](https://appdefensealliance.dev/casa/tier-2/tooling-matrix) 
> now. There might not exist a way to do this which does not require 
> providing some company with access to all source code of MailMate. I'm 
> not sure I'm willing to do that although I guess that would also mean 
> that Apple, Microsoft, and every other email client developer out 
> there would have to do the same thing.
>
> Note that I'm not saying code scanning is bad. You are welcome to 
> recommend the use of any tool you think would be useful in my build 
> process. As required by Apple, MailMate uses a [hardened 
> runtime](https://developer.apple.com/documentation/security/hardened-runtime?language=objc). 
> While developing I use an [address 
> sanitizer](https://clang.llvm.org/docs/AddressSanitizer.html) and 
> [library 
> hardening](https://developer.apple.com/xcode/cpp/#library-hardening). 
> Recently, I also enabled the latter in its “fast” mode for test 
> builds.
>
> ---
> ### Trust
>
> I could write a lot about the current CASA assessment being mostly 
> irrelevant for a desktop email client, but this is not my primary 
> critique CASA. In theory the assessment could be a really good process 
> and the source code scanners might actually be able to find issues in 
> MailMate code, but this does not mean that a user should put more 
> *trust* into a verified app than a non-verified app when 
> authenticating via OAuth. This is because the assessment is entirely 
> done in “good faith”. The developer can lie through the whole 
> thing and all you really know when an app is verified is that the 
> developer paid for it.
>
> Would this be better if the developer was not allowed to self-assess 
> it? No, even if sending the source code elsewhere for assessment, the 
> developer would still be in control of the source code sent.
>
> In any case, the assessment provides no protection against any issues 
> introduced *after* the assessment, that is, the entire source code 
> could be replaced and it would have no effect on the verification 
> status (until the next assessment).
>
> By contrast, the hardening required by Apple is verified for every 
> upload/release of MailMate. This is a real safety measure not based on 
> “good faith”.
>
> ---
> ### OAuth
>
> It's also useful to return to what we are really trying to do here. 
> The problem with the old authentication methods for IMAP/SMTP was that 
> they were mostly username/password based. If someone stole/guessed 
> your password then your account could be misused from anywhere. The 
> OAuth method is more flexible and it allows the introduction of 2FA 
> making access to your account much safer. The email client never knows 
> your password, but it does get a refresh token instead. If this is 
> stolen then you have the same problem as before unless the refresh 
> token is often updated (only Fastmail does this in the implementations 
> I have seen). Using OAuth to be able to use 2FA is a great idea. No 
> complaints from me. Note that a general standardization of the use of 
> OAuth for desktop apps (native clients) is a 
> [work-in-progress](https://datatracker.ietf.org/doc/html/draft-ietf-mailmaint-oauth-public). 
> This might bring OAuth to more IMAP server implementations.
>
> In theory, the OAuth process also allows the email provider to control 
> which email clients have access to the account and that might sound 
> great, but it doesn't really work in practice. For example, if a 
> MailMate refresh token was stolen then it can be used by any other 
> app/script because the refresh token is not effectively limited to be 
> used by MailMate. This is because any app/script can pretend to be 
> MailMate. This also means that some malware app/script can be named 
> MailMate and if the user doesn't know any better then they might 
> accept providing access to this app/script when Google asks them. In 
> this situation, Google might detect the problem and revoke MailMate 
> access which would then affect all real MailMate users as well. One 
> might be tempted to think that this is a broken feature of OAuth when 
> used with a desktop app...
>
> Essentially, the only way to really block an app/script from accessing 
> a Gmail account via IMAP/SMTP is to block *all* apps/scripts from 
> access.
>
> ---
> ### Deadline
>
> Google has provided me with a deadline, May 7, 2025, but I've asked 
> for a postponement on the grounds that I'm still working on the public 
> release of MailMate 2.0. For transparency, I've also told them that 
> it's likely that I won't go through the assessment again even if I do 
> get this postponement. I'm sure a lot of users will ask me why I don't 
> just pay up, but I'm simply tired of spending time on considering what 
> Google might or might not require of me in the future. Apple is doing 
> just fine in that regard. I've literally spent months on making Gmail 
> work in MailMate, because it's very far from being a standard IMAP 
> implementation. The workarounds required were ridiculously complicated 
> (and it's probably still not perfect). I guess you can say I'm tired 
> of working for Google for free and I really do not want to start 
> paying them (or their assessment company friends) to have the 
> privilege, every year, to get their security theater badge.
>
> ---
> ### Gmail support in the future
>
> Ok, no more ranting. What does this mean for Gmail support in the 
> immediate future? Well, maybe not much if I understand the inner 
> workings of Google authentication correctly.
>
> I've written a new server page describing various [account 
> configuration](http://freron.com/account_configuration/) issues. Here 
> is the current part on workarounds if MailMate is no longer a Google 
> verified app:
>
> * Simple solution (OAuth-based): Google Workspace (aka G Suite aka 
> Google Apps) users should be able to have the admin of the account 
> explicitly allow MailMate. This should mean that OAuth still works for 
> the account.
> * Simple solution (password-based): Free `@gmail.com` accounts do not 
> have settings allowing the user to explicitly allow MailMate. Instead, 
> you need an app specific password. This option is very well hidden 
> though, but here is a [direct 
> link](https://myaccount.google.com/apppasswords). Note that this 
> [requires 2SV](https://support.google.com/accounts/answer/185833) to 
> be enabled for the account.
> * Advanced solution (OAuth-based): It's also possible to make your own 
> [app 
> registration](https://developers.google.com/identity/protocols/oauth2/native-app) 
> with Google and then use these credentials with MailMate using the 
> `MmGmailOAuth2ClientID` and `MmGmailOAuth2ClientSecret` hidden 
> preference values.
>
> There's a fourth solution described on the website, but I'd prefer if 
> that one was not used and I'm leaving it out here.
>
> I've been using Gmail recently with an app specific password without 
> any issues. I'm interested in knowing if the first solution above 
> works for Google Workspace users. Well, I'm interested in knowing if 
> an admin can find this setting. It would also be interesting to know 
> if app passwords are allowed for Google Workspace users.
>
> -- 
> Benny
> _______________________________________________
> mailmate mailing list
> Unsubscribe: https://lists.freron.com/listinfo/mailmate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20250409/2e3820dd/attachment-0001.htm>