Hi Benny,
I've not used Gmail in a **long** time (thank goodness), but I
occasionally get glimpses into the current state of Google's
'maintenance' of that part of their empire when troubleshooting my
mother's email. (She's just fine with Apple's Mail app for now.) If I
remember correctly, she has 2FA plus an app password, which is what I
also use with Fastmail for all the apps I have that need to access.
While I kinda-sorta understand why OAuth _might_ be a good thing, from
what you've written it sounds like Google is using it primarily for
their benefit. It _would_ be mighty convenient if fewer people were
using third-party apps to access their Gmail, and opting to access
through the browser (ideally Chrome, from Google's viewpoint) or the
official Gmail app...
I wish I wasn't so cynical about this, but then Google has shown its
hand more than enough times in the past that I keep my (now limited) use
of their services as arms-length and brief as possible. (My thoughts on
Google Drive probably aren't repeatable in polite company.) I just
checked my Google Account page, and had to resort to Help to find the
app passwords page, so it definitely gives credence to Google pushing
folks towards OAuth and away from third-party apps & services.
--
Alan
On 9 Apr 2025, at 14: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
