Depressing, but thanks. One pain point: those of us who work for large organizations that have outsourced email to Google. Trying to get the admins of a large organization to approve something non-standard is, umm, painful…
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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freron.com_mailmate_2024-2DJune_017271.html&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=IoK0TtU5pHVWDF1T_TfxC1UV7I0ko0KpjotekXCwL2c&e= > ). > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__appdefensealliance.dev_casa_casa-2Dassessors&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=tkwEw3Uhg9Knl4yawfnKxpngv0PmLvike1FllpP-c3U&e= > ) (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://urldefense.proofpoint.com/v2/url?u=https-3A__casa.tacsecurity.com_site_home&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=lg-TkZWNvnIhv69QQA91RhjPoVRFZ4SMdRsypCBEp7U&e= > ). 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://urldefense.proofpoint.com/v2/url?u=https-3A__blog.freron.com_2024_new-2Dlicense-2Dkey-2Dsystem_&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=vz8bwCqBEhuOKR4MaNVS_lOxqcIpzFplyqKxC3OjL10&e= > ) 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freron.com_mailmate_2024-2DJune_017271.html&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=IoK0TtU5pHVWDF1T_TfxC1UV7I0ko0KpjotekXCwL2c&e= > ), 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://urldefense.proofpoint.com/v2/url?u=https-3A__appdefensealliance.dev_casa_tier-2D2_tooling-2Dmatrix&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=NLM-s9-a5AWBVYiPpmMNhOtckJlkDFnsU2rn7NNHR3w&e= > ) 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://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.com_documentation_security_hardened-2Druntime-3Flanguage-3Dobjc&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=0SFbUrHTEy8bNGCv16zlI3aOyDyGT2d1-G8VVTDtG8g&e= > ). While developing I use an [address > sanitizer](https://urldefense.proofpoint.com/v2/url?u=https-3A__clang.llvm.org_docs_AddressSanitizer.html&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=cfs644cp2mEFaD3O4HfCMgmZ-ZzgZ1T9ibFI7PwUYSE&e= > ) and [library > hardening](https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.com_xcode_cpp_-23library-2Dhardening&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=5w4ULJUFsPGa7216GvppcvKYNptJi_h2a1o2nx1XZQE&e= > ). 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dmailmaint-2Doauth-2Dpublic&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=2MN2KxIDgPgqitXM9sdyfVxcgboHTQbNOEdnID2opLM&e= > ). 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](https://urldefense.proofpoint.com/v2/url?u=http-3A__freron.com_account-5Fconfiguration_&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=-Ss_XRv5nofCWJ11FhaZDc1cm3AplyphRWo9bs2XrN8&e= > ) 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://urldefense.proofpoint.com/v2/url?u=https-3A__myaccount.google.com_apppasswords&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=Spx1rCmQvKkuWd1_t57rxlong2hb9fbCpoSNQC4ufks&e= > ). Note that this [requires > 2SV](https://urldefense.proofpoint.com/v2/url?u=https-3A__support.google.com_accounts_answer_185833&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=u4lq8B5zxDIck_xcyzCQtALL3gEkytuMmB0B0giccYM&e= > ) to be enabled for the account. > * Advanced solution (OAuth-based): It's also possible to make your own [app > registration](https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.google.com_identity_protocols_oauth2_native-2Dapp&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=R9xkpzX5ufyVL5rErGG7NsTkiic5LiMiamArLzLWzuU&e= > ) 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freron.com_listinfo_mailmate&d=DwIGaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=jMObdJSnQpbSLekl2NjvrJVVxCKbmtg8cvi5143NF8Q&m=U4t89-PLDVt-lWWjDJtXriMP1Lx7EM0w8g9I_8vMZolL9GbizFWN0knguHjXBQej&s=qktrjyWyYg_QBE6BZ3HmQzM3EKbLu988QmT6wL4W3Pg&e= --Steve Bellovin, https://www.cs.columbia.edu/~smb _______________________________________________ mailmate mailing list Unsubscribe: https://lists.freron.com/listinfo/mailmate
