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

[Benny Kjær Nielsen]

**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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20250409/51f71d8e/attachment-0001.htm>