Emulate "Less Secure Apps" with Email OAuth 2.0 Proxy

Email OAuth 2.0 Proxy is a local IMAP/POP/SMTP proxy that adds OAuth 2.0 authentication transparently, allowing email clients that don't support OAuth to keep working unchanged. From the README:

"Email services that support IMAP, POP and/or SMTP access are increasingly requiring the use of OAuth 2.0 to authenticate connections, but not all clients support this method. This tool is a local proxy that intercepts the traditional IMAP/POP/SMTP authentication commands and transparently replaces them with the appropriate SASL (X)OAuth 2.0 commands and credentials. Your email client, app or device can continue to use the login or auth/authenticate options, with no need to make it aware of OAuth's existence. The proxy works in the background with a menu bar/taskbar helper or as a headless system service, and is compatible with macOS, Windows and Linux. It can be used with any email provider that supports OAuth 2.0 authentication, including Outlook, Office 365, Hotmail, 21Vianet, Gmail, Google Workspace, Fastmail, Yahoo, Comcast, AOL and many others."

❧ 2026-01-06


Beware Apple's MobileSentrix recommendation

Needing a Mac Pro (2019) power supply, I started at Apple's Self Service Repair Store.

Only the Mac Pro (2023) PSU was listed, so I clicked Find Out About Self Service Repair, which states that "Genuine Apple parts can also be purchased from a Genuine Parts Distributor":

"To repair Apple products, purchase genuine Apple parts from a Genuine Parts Distributor and reference the repair manual for your device.

...

"In the United States, parts can be purchased from this Genuine Parts Distributor:

"A Genuine Parts Distributor may require account creation or sign-in prior to order placement. See the distributor’s site for more information."

Not finding the part listed on MobileSentrix, I clicked the prominent chat bubble and asked whether it was available. I was informed that:

"At this time, in order for us to assist you with sourcing this part, you would first need to create an account with us. Since we operate on a B2B basis, we require valid business documentation to verify your account. Unfortunately, without this verification, we are unable to assist with sourcing the Mac Pro (2019) power supply."

No problem; I am a business customer and happy to create an account (though the B2B requirement seemed a little odd in light of Apple's "To repair Apple products, purchase genuine Apple parts from a Genuine Parts Distributor and reference the repair manual for your device."):

"Thank you for your understanding, and I appreciate your willingness to set up an account. Once you have completed the account setup, please return to this thread and let us know. We will be more than happy to assist you with sourcing the Mac Pro (2019) power supply and any other parts you may need."

Great! Set up the account as requested and was then informed:

"Please send your business license and government-issued ID to our onboarding team. Once your account is approved, we can proceed with sourcing the part for you. Please keep us updated once approval is complete."

I asked why a personal government-issued ID was required for a corporate account and was told that it "is a required part of the onboarding process even for corporate accounts."

OK, redacted the most sensitive bits on my driver's license with Preview and watermarked via iWatermark+ (for what it's worth), then sent along with the business registration.

Five days later, received this message:

"Thank you for sending over the requested documents. Unfortunately, we are strictly business to business wholesale suppliers who only service established brick and mortar phone repair shops. Due to this, we are unable to have your account approved. I apologies [sic] for any inconvenience that this may cause you"

True, my business does operate exclusively onsite and remotely; it might've been nice for Apple or MobileSentrix to mention a brick-and-mortar store requirement somewhere along the way before submitting sensitive documentation.

If only I had read Replace the power supply in your Mac Pro (2019) more carefully; it clearly states, "If you need to order a replacement power supply, contact Apple." Sure enough, they happily sold me the unlisted PSU by phone, no waiting, ID, or business documentation required!

❧ 2026-01-03


Mount any Linux-supported filesystem in macOS,

without installing kernel extensions or weakening system security, via anylinuxfs. Built on the libkrun microVM hypervisor and NFS, it provides read/write access to virtually any Linux-compatible filesystem (ext4, btrfs, xfs, ZFS, NTFS*, exFAT, etc.), encrypted volumes (LUKS, BitLocker), and advanced storage configurations (LVM, RAID, multi-disk setups). Works with internal/external drives, disk images, and GPT, MBR, or raw partition formats.

❧ 2026-01-01


Microsoft mishandling example.com

TL;DR: Since at least February 2020, Microsoft's Autodiscover service has incorrectly routed the IANA-reserved example.com to Sumitomo Electric Industries' mail servers at sei.co.jp, potentially sending test credentials there.

Problem

While setting up email@example.com as a dummy account in Outlook (on both Windows and macOS), Outlook consistently auto-configured it to use imapgms.jnet.sei.co.jp (IMAP) and smtpgms.jnet.sei.co.jp (SMTP) despite example.com being an IANA-reserved domain that should not resolve to real services.

The same behavior appeared on different machines, profiles, networks, and DNS resolvers, including a newly provisioned Windows 365 Cloud PC:

Confirmation

DNS verification

Confirm that example.com has no DNS records pointing to sei.co.jp:

% dig MX example.com +short
0 .

% dig CNAME autodiscover.example.com +short
(no response)

% dig SRV _autodiscover._tcp.example.com +short
(no response)

The domain has a null MX record (indicating it doesn't accept email) and no Autodiscover DNS entries, confirming the misconfiguration exists entirely within Microsoft's database.

Microsoft autodiscover API response

Microsoft's Autodiscover service misconfiguration can be confirmed via curl -v -u "email@example.com:password" "https://prod.autodetect.outlook.cloud.microsoft/autodetect/detect?app=outlookdesktopBasic":

View full output

* Host prod.autodetect.outlook.cloud.microsoft:443 was resolved.
* IPv6: (none)
* IPv4: 172.169.69.94
*   Trying 172.169.69.94:443...
* Connected to prod.autodetect.outlook.cloud.microsoft (172.169.69.94) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=WA; L=Redmond; O=Microsoft Corporation; CN=autodetect.outlookmobile.com
*  start date: Nov  1 12:31:46 2025 GMT
*  expire date: Jan 30 12:31:46 2026 GMT
*  subjectAltName: host "prod.autodetect.outlook.cloud.microsoft" matched cert's "*.autodetect.outlook.cloud.microsoft"
*  issuer: C=US; O=Microsoft Corporation; CN=Microsoft Azure RSA TLS Issuing CA 03
*  SSL certificate verify ok.
* using HTTP/2
* Server auth using Basic with user 'email@example.com'
* [HTTP/2] [1] OPENED stream for https://prod.autodetect.outlook.cloud.microsoft/autodetect/detect?app=outlookdesktopBasic
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: prod.autodetect.outlook.cloud.microsoft]
* [HTTP/2] [1] [:path: /autodetect/detect?app=outlookdesktopBasic]
* [HTTP/2] [1] [authorization: Basic ZW1haWxAZXhhbXBsZS5jb206cGFzc3dvcmQ=]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET /autodetect/detect?app=outlookdesktopBasic HTTP/2
> Host: prod.autodetect.outlook.cloud.microsoft
> Authorization: Basic ZW1haWxAZXhhbXBsZS5jb206cGFzc3dvcmQ=
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 200 
< content-type: application/json; charset=utf-8
< date: Mon, 08 Dec 2025 21:32:58 GMT
< server: Kestrel
< strict-transport-security: max-age=2592000
< x-olm-source-endpoint: /detect
< x-provider-id: seeatest
< x-debug-support: eyJkZWNpc2lvbiI6ImF1dG9EdjIgPiBhdXRvRHYxID4gZml4ZWQgZGIgcHJvdmlkZXIgPiBmaXhlZCBkYiBkb21haW4gcHJvdG9jb2xzID4gZGIgcHJvdmlkZXIgPiBkYiBkb21haW4gcHJvdG9jb2xzIiwiYXV0b0QiOnsidjIiOm51bGwsInYxIjpudWxsfSwiZGIiOnsicHJvdmlkZXIiOnsiRG9tYWluSWQiOm51bGwsIklkIjoic2VlYXRlc3QiLCJTZXJ2aWNlIjpudWxsLCJQcm90b2NvbHMiOlt7InByb3RvY29sIjoic210cCIsIkRvbWFpbiI6bnVsbCwiSG9zdG5hbWUiOiJzbXRwZ21zLmpuZXQuc2VpLmNvLmpwIiwiUG9ydCI6NDY1LCJFbmNyeXB0aW9uIjoiU3NsIiwiSXNDcm93ZHNvdXJjZWQiOm51bGwsIkZlZWRiYWNrcyI6bnVsbCwiSW5zZWN1cmUiOm51bGwsIlNlY3VyZSI6IlRydWUiLCJVc2VybmFtZSI6IntlbWFpbH0iLCJWYWxpZGF0ZWQiOmZhbHNlLCJBdXRvZGlzY292ZXIiOm51bGwsIkFhZCI6bnVsbH0seyJwcm90b2NvbCI6ImltYXAiLCJEb21haW4iOm51bGwsIkhvc3RuYW1lIjoiaW1hcGdtcy5qbmV0LnNlaS5jby5qcCIsIlBvcnQiOjk5MywiRW5jcnlwdGlvbiI6IlNzbCIsIklzQ3Jvd2Rzb3VyY2VkIjpudWxsLCJGZWVkYmFja3MiOm51bGwsIkluc2VjdXJlIjpudWxsLCJTZWN1cmUiOiJUcnVlIiwiVXNlcm5hbWUiOiJ7ZW1haWx9IiwiVmFsaWRhdGVkIjpmYWxzZSwiQXV0b2Rpc2NvdmVyIjpudWxsLCJBYWQiOm51bGx9XSwiQ3JlYXRlZEF0IjoiMjAyMC0wMi0wM1QwNTozMToyMy4yOTgwMjQ4IiwiVXBkYXRlZEF0IjoiMjAyMC0wMi0wM1QwOToxMjo1OS4wMjQ1ODciLCJQcmVkaWNhdGVzIjpudWxsLCJBdXRvRHYyRW5kcG9pbnQiOm51bGwsIkNvbW1lbnQiOm51bGwsIkZlZWRiYWNrcyI6bnVsbCwiSXNDcm93ZHNvdXJjZWQiOmZhbHNlfSwiZG9tYWluIjp7ImZpeGVkIjpmYWxzZSwiYXV0b0R2MkVuZHBvaW50IjpudWxsLCJwcm92aWRlcklkIjoic2VlYXRlc3QiLCJwcm90b2NvbHMiOm51bGx9fX0=
< x-autodv2-error: ENOTFOUND
< x-feedback-token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJEIjoiZXhhbXBsZS5jb20iLCJQSSI6InNlZWF0ZXN0IiwiUyI6W10sIlAiOlsiaW1hcHM6Ly9pbWFwZ21zLmpuZXQuc2VpLmNvLmpwOjk5MyIsInNtdHBzOi8vc210cGdtcy5qbmV0LnNlaS5jby5qcDo0NjUiXSwiUFQiOiJpbWFwIHNtdHAiLCJleHAiOjE3NjUyMzMxNzgsImlhdCI6MTc2NTIyOTU3OH0.-ohD7c9hytRZK_b4EJ0M5Tke7hl8u1wjsMYRV71GZik
< x-dns-prefetch-control: off
< x-frame-options: SAMEORIGIN
< x-download-options: noopen
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< x-instance-id: autodetect-deployment-76fffc487d-wfs4b
< x-response-time: 3472 ms
< x-request-id: f1b6525f-6d11-4add-a0e4-0b677d89f9eb
< x-autodetect-cv: f1b6525f-6d11-4add-a0e4-0b677d89f9eb
< 
* Connection #0 to host prod.autodetect.outlook.cloud.microsoft left intact
{"email":"email@example.com","services":[],"protocols":[{"protocol":"imap","hostname":"imapgms.jnet.sei.co.jp","port":993,"encryption":"ssl","username":"email@example.com","validated":false},{"protocol":"smtp","hostname":"smtpgms.jnet.sei.co.jp","port":465,"encryption":"ssl","username":"email@example.com","validated":false}]}%

The JSON response:

{
  "email": "email@example.com",
  "services": [],
  "protocols": [
    {
      "protocol": "imap",
      "hostname": "imapgms.jnet.sei.co.jp",
      "port": 993,
      "encryption": "ssl",
      "username": "email@example.com",
      "validated": false
    },
    {
      "protocol": "smtp",
      "hostname": "smtpgms.jnet.sei.co.jp",
      "port": 465,
      "encryption": "ssl",
      "username": "email@example.com",
      "validated": false
    }
  ]
}

Decoded debug header

The x-debug-support header (Base64-decoded) reveals additional details:

Field Value
Provider ID seeatest
Created 2020-02-03 05:31:23 UTC
Updated 2020-02-03 09:12:59 UTC
IsCrowdsourced false

This misconfiguration has existed for nearly six years and was not crowdsourced. It appears to have been manually added to Microsoft's database.

Related

❧ 2026-01-01