Research Spike: Mail Access Route for Recruiter-Correspondence Extraction (WING-380)¶

Status: spike / no code changes. Research only, current as of 2026-08-05.

Plain-language companion: What recruiter mail access can and cannot do.

Current product constraint¶

Work Wingman currently has recruiter-message parsing and ranking domain services, but no mailbox HTTP producer and no connected-mailbox workflow. Recruiter Reactivation must remain explicitly unavailable: ranking code is not evidence that a mailbox was searched. No mailbox claim may be enabled until the chosen producer passes privacy, credential-handling, provider-policy, security, reliability, and fail-closed UI gates.

Question¶

WorkWingman's desktop Electron app + companion browser extension need to read a user's mail across Gmail, Outlook/Microsoft 365, Yahoo, iCloud, and generic IMAP to extract recruiter correspondence. Message bodies are required — employer identity does not appear in metadata (sender/subject) alone in most recruiter emails — so metadata-only scopes (e.g. Gmail gmail.metadata, Graph Mail.ReadBasic) do not qualify for this feature.

Three candidate routes are evaluated: (1) browser-extension DOM reading of the already authenticated webmail session, (2) desktop-local reading of a local mail store or IMAP with a user-supplied app password, (3) per-provider OAuth with full-body scopes.

How to read this document¶

Every factual claim below is followed by a citation. Where I could not retrieve or verify a primary source directly, the claim is labeled UNVERIFIED with a note on what would confirm it.
Confirmed = read directly from a primary source (vendor docs/policy pages) in this spike.
Inferred = a conclusion I drew by combining confirmed facts; flagged explicitly so it is not mistaken for a directly-stated vendor position.
Unverified = I could not retrieve primary-source confirmation; the claim rests on secondary sources (blogs, aggregators) or was not retrievable at all in this session.

Route 1 — Browser Extension DOM Reading¶

The extension runs as a content script inside the user's already-authenticated webmail tab and reads the rendered DOM (or the accessibility tree) rather than calling any provider API.

1a. Does DOM reading trigger Google's restricted-scope verification / CASA? (the key unknown)¶

Confirmed: Google's restricted-scope verification process is explicitly scoped to "apps that request access to scopes categorized as sensitive or restricted" through Google's OAuth Authorization APIs — i.e., it is anchored to an OAuth scope request, not to "does your software display Gmail data." See Restricted scope verification and the OAuth API Verification FAQ. The annual security assessment (CASA) is likewise defined as applying to apps that "access Google users' restricted data and has the ability to access data from or through a third-party server" — again anchored to the OAuth grant, per Security Assessment FAQ.

Inferred (high confidence, not stated verbatim by Google): An extension that never requests a Google OAuth scope and never calls a Gmail/Google API — because it reads the rendered mail.google.com page the user is already signed into via their own browser session — does not enter Google's OAuth verification pipeline at all, and therefore does not trigger restricted-scope verification or CASA. No Google document says "DOM-reading extensions are exempt" in those words; this is a logical consequence of the verification framework's scope (it governs OAuth clients, and a DOM-reading extension is not an OAuth client). This is corroborated by community discussion confirming that DOM-based Gmail readers (e.g., the unofficial gmail.js library) operate outside Google's API/verification surface — see search results summarized around gmail.js — but that is a secondary/community source, not Google policy text, so treat the underlying mechanism (OAuth-scope-triggered) as confirmed and the extension-specific conclusion as inferred.

Important scope boundary: the moment the extension (or the desktop app behind it) also wants to act through the Gmail API for convenience — e.g., calling gmail.readonly to fetch full threads instead of scraping them, marking messages read, or sending — it becomes an OAuth client and the full verification/CASA machinery in Route 3 applies. DOM reading only stays outside that pipeline as long as it never touches the API.

A second, separate review layer still applies regardless of API use. The Chrome Web Store's own Program Policies (not part of Google's OAuth/Identity pipeline) govern any extension that collects user data, including data scraped from a webpage's DOM. This is the Limited Use policy covered next — it is real review exposure, just a different and generally lighter one than CASA.

1b. Chrome Web Store "Limited Use" policy: what does single-purpose disclosure permit?¶

Confirmed, from Limited Use | Chrome Web Store Program Policies: - "Extensions may only collect, use, or transmit user data that is necessary for the extension's disclosed single purpose." - Collection of web browsing activity is prohibited "except to the extent required for a user-facing feature described prominently in the Product's Chrome Web Store page" and in the product's own interface. - Developers must publish an affirmative Limited Use compliance statement, typically on a privacy policy page.

Confirmed, from the Extensions quality guidelines FAQ: a single extension can offer multiple related functions if they share one narrow focus area or subject matter — Google's own example is a shopping extension that both shows recent deals and finds coupons, because both relate to "shopping." Quoted verbatim: "An extension can have a single purpose limited to a narrow focus area or subject matter (for example, 'news headlines', 'weather', 'comparison shopping'). If the extension has a narrow focus area or subject matter, then it can offer various functions related to that focus area."

Inferred, applied to WorkWingman: "detect employer responses to your applications" and "find past recruiter conversations" both sit inside one narrow subject-matter purpose — something like "organizes job-search-related email for the user" — and by Google's own shopping-extension example these plausibly qualify as one disclosed purpose rather than requiring two separate extensions. This is not a guarantee: Chrome Web Store review is manual and outcome-dependent on how the purpose statement and screenshots are worded; the safest posture is to write one tight purpose statement ("organize and surface job-application email") and keep every requested permission and every described feature legibly inside it.

Confirmed policy currency: Chrome tightened this area again in July 2026 — prominent disclosure of all data collection is now required "regardless of whether the data is closely related to the extension's single purpose," and developers must proactively disclose any change in data-handling practice after install; enforcement began 2026-08-01. See Chrome Web Store policy updates: Enhancing user privacy and platform integrity.

1c. Gmail's CSP on mail.google.com — extension breakage, current state¶

Confirmed: Google has been rolling Trusted Types enforcement out to Gmail (Content-Security-Policy: require-trusted-types-for 'script'), see Google Workspace Updates: Extending Trusted Types to Gmail. Trusted Types blocks scripts from assigning attacker-controllable strings into dangerous DOM sinks (innerHTML, document.write, etc.) without going through a registered policy.

Confirmed, historical breakage case: the Mixmax Chrome extension broke when Gmail introduced a CSP because Mixmax injected a <script> tag directly into the Gmail page to extend its compose UI; that tag then ran inside the page's own execution context and was subject to the page's script-src CSP — see Gmail Just Broke Every Chrome Extension. Here's How We Fixed Ours — Mixmax Engineering.

Inferred distinction (this materially changes the risk assessment for WorkWingman): the documented breakage pattern is specific to extensions that inject page-world <script> tags to extend Gmail's own functionality (composing, UI hooks). A Manifest V3 content script that only reads the rendered DOM (textContent/innerText, or the accessibility tree) to extract message bodies does not assign to a Trusted-Types-gated sink and is not blocked by that mechanism; Chrome extension content scripts also run in an isolated JS world and are not subject to the page's own script-src CSP for their own script execution (general Chromium/WebExtension architecture, not Gmail-specific). Net: passive extraction is architecturally lower-risk than the historical breakage pattern, but this is my synthesis of the two cited facts, not a Google statement that says "read-only content scripts are safe on Gmail." Unverified / needs a hands-on check: Gmail's DOM structure and CSS class names are unstable and change without notice (well-known engineering risk of any DOM-scraping approach, not specific to this citation) — a working extraction selector set requires an ongoing maintenance commitment and should be smoke-tested against current Gmail markup before this route is chosen as primary.

1d. Equivalent constraints on Outlook Web, Yahoo Mail, iCloud Mail¶

UNVERIFIED for all three. I could not find a primary Microsoft, Yahoo, or Apple document stating the current CSP header value or Trusted Types status for outlook.office.com / outlook.live.com, mail.yahoo.com, or www.icloud.com/mail, and WebFetch could not retrieve the JS-rendered content of the pages I attempted. What is confirmed instead: - Outlook Web's CSP is documented in the context of Office Add-ins — a separate, sandboxed iframe extension model distinct from generic browser extensions — restricting script sources to Microsoft-owned CDN domains; see Privacy and security for Office Add-ins. This does not directly answer whether a generic content script can read the OWA DOM. Add-ins run same-origin-isolated by design, which is a different mechanism from a page CSP blocking third-party content scripts. - No public documentation was found describing Yahoo Mail or iCloud Mail CSP headers or extension breakage incidents comparable to the Gmail/Mixmax case.

What would verify this: open each webmail client in Chrome DevTools → Network tab, inspect the Content-Security-Policy response header on the main document request, and load a minimal test content script that reads document.body.innerText to confirm it executes and can see message text. This is a same-day check, not a research task — recommend doing it before committing engineering time to this route.

1e. Firefox/Edge/Safari store equivalents of "Limited Use"¶

Confirmed — Firefox (AMO): Mozilla now requires all new extensions, starting 2025-11-03, to declare data collection practices via the browser_specific_settings.gecko.data_collection_permissions manifest key (including an explicit "we collect nothing" declaration where true), surfaced at install time and on the listing page; full requirement for all add-ons lands mid-2026. See Updated Add-on policies — simplified, clarified and coverage in Mozilla: New Firefox extensions must disclose data collection practices. This is a declarative-disclosure regime, not a narrative single-purpose review, but it serves the same transparency goal as Chrome's Limited Use policy.

Confirmed — Microsoft Edge Add-ons: Microsoft's developer policy uses language that closely mirrors Chrome's: an extension "may collect, access, use, or transmit personal information (including web browsing activity) only if required by and only for use in a prominently disclosed, user-facing feature," and developers must submit a single-purpose statement, permission justifications, and a dedicated privacy policy as part of the review flow. See Developer policies for the Microsoft Edge Add-ons store. Practically, Edge = Chrome's regime with Microsoft's own submission flow.

UNVERIFIED — Safari: no Chrome-style "Limited Use"/single-purpose extension-store policy was found. Safari Web Extensions ship through the Mac/iOS App Store and are subject to Apple's general App Review Guidelines plus mandatory "Privacy Nutrition Label" disclosure in App Store Connect (see App Privacy Details), which is a different compliance model (declared data-use categories + general app review) rather than a browser-extension-specific single-purpose doctrine. I did not find 2026-specific guidance narrowing this further; treat Safari as its own review track requiring a real submission to characterize fully.

Route 2 — Desktop-Local (local mail store, or IMAP with a user-supplied app password)¶

2a. Local Outlook / Thunderbird store reading (no provider-store/OAuth review; still product privacy/security gated)¶

Confirmed, general facts, not vendor policy: Outlook's local cache is a proprietary OST/PST binary format; open-source parsers exist (pst-extractor on npm, node-libpst, pffexport/libpff) alongside commercial SDKs (Aspose.Email). Thunderbird's local store is the Berkeley mbox flat-file format at a documented profile path (%AppData%\Roaming\Thunderbird\Profiles\<profile>\Mail or ImapMail), parseable with libraries like node-mbox plus a MIME parser (mailparser) for message bodies; see Profiles — Where Thunderbird stores your messages. This path avoids provider-store and OAuth review (no extension store, OAuth scope, or webmail CSP), but it still reads full-mailbox content. It cannot ship without explicit disclosure, minimization/retention limits, no cloud logging of message bodies, product security review, and a fail-closed UI. It only reaches users who (a) run a desktop mail client at all, (b) run Outlook classic or Thunderbird specifically, and (c) keep local caching/offline mail enabled — a materially smaller and more technical population than "anyone with a Gmail/Outlook/Yahoo/iCloud account." Unverified: current OST encryption/version compatibility across Outlook builds — Microsoft has changed the OST format across versions and parser support lags; would need a build-by-build compatibility check against the parser chosen.

2b. Microsoft: current IMAP/app-password/basic-auth status¶

Confirmed: Basic Authentication is fully disabled, with no re-enable path, for Exchange ActiveSync, POP, IMAP, Remote PowerShell, EWS, Offline Address Book, Autodiscover, and Outlook for Windows/Mac in Exchange Online (org/M365 tenants), effective since 2022–2023; see Deprecation of Basic authentication in Exchange Online (fetched directly). The same page states explicitly: "The deprecation of basic authentication also prevents the use of app passwords with apps that don't support two-step verification." Microsoft's own guidance for POP/IMAP is: implement OAuth 2.0 (XOAUTH2) against the Microsoft identity platform — there is no ongoing basic-auth or app-password fallback comparable to Google/Yahoo/Apple's mechanism. The page also states Outlook's own desktop client has "no plan…to support OAuth for POP and IMAP" and instead uses MAPI/HTTP or EWS — proprietary protocols not usable by a third-party Electron app.

Confirmed (this session's fetch succeeded for org tenants; personal-account timeline retrieved only via search snippets, not a full primary fetch — flagged below): SMTP AUTH basic authentication is being retired in phases during 2026, described in Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline — I could not retrieve this page's full body (WebFetch returned only the title twice, likely due to client-rendered content); the phased dates below come from a secondary aggregator citing that post and should be re-verified directly against the Microsoft URL before being used in any customer-facing claim: - UNVERIFIED (secondary source only): phased rejection of Basic-Auth SMTP submissions begins 2026-03-01, reaching 100% rejection by 2026-04-30, with SMTP AUTH basic auth disabled by default tenant-wide by end of December 2026 — per Microsoft's Modern Authentication Enforcement in 2026. - UNVERIFIED (secondary source only): deprecation of Basic Authentication for personal Outlook.com/Hotmail accounts took effect 2026-09-16 [sic — the search snippet returned this date without a year prefix I could independently confirm]; primary post title is Keeping our Outlook Personal Email Users Safe but body content was not retrievable by WebFetch in this session — re-fetch with a headless browser or curl before relying on this date.

Net for Microsoft, high confidence: whatever the exact 2026 date, the direction is unambiguous and already confirmed at the primary-source level for org tenants — Microsoft mail (both Exchange Online/M365 and, per secondary sources, personal Outlook.com) has no durable IMAP app-password path. Route 2 is not viable for Microsoft as a stable long-term design; any Microsoft integration is pushed into Route 3 (OAuth) regardless of which route is chosen for other providers.

2c. Google app passwords¶

Confirmed, from App Passwords support (fetched directly): app passwords require 2-Step Verification to be enabled, and are unavailable for accounts where 2SV is set up only with security keys, accounts under Advanced Protection, and most work/school (Workspace-managed) accounts. Google's own copy calls app passwords "not recommended and… unnecessary in most cases," steering developers toward OAuth ("Sign in with Google"), but the page does not state a removal/end-of-life date as of this fetch. UNVERIFIED / conflicting: a secondary source claims "Gmail is phasing out app passwords in 2026" — see Gmail OAuth 2.0 Changes 2026: App Password Phase-Out — this is not corroborated by the primary support page fetched above (which shows no removal date) and should be checked against the Google Workspace Updates blog before being treated as fact. Separately confirmed: Google Workspace (business/enterprise) already permanently disabled Basic Authentication (username+password) for IMAP/POP/SMTP as of the "Transition from less secure apps to OAuth" deadline of 2025-03-14 — see Transition from less secure apps to OAuth. App passwords are a distinct mechanism from "less secure apps" and remain the supported non-OAuth path for personal Gmail accounts today, per the support page above.

2d. Yahoo Mail app passwords¶

Confirmed (partial — could not fully retrieve primary content): Generate and manage 3rd-party app passwords describes generating an app password via "External connections" on the Yahoo Account Security page for non-Yahoo apps that don't use Yahoo's own sign-in page; WebFetch could retrieve only partial page content and could not confirm from the primary page whether Two-Step Verification is a hard prerequisite (secondary sources consistently say yes — e.g. Yahoo Mail App Password: 2026 Troubleshooting Guide — but this should be confirmed by actually attempting to generate one on a 2SV-disabled test account). No stated deprecation timeline was found for this mechanism.

2e. iCloud Mail app-specific passwords¶

Confirmed via secondary sources; primary Apple page (support.apple.com/en-us/102654) could not be fully retrieved by WebFetch in this session (JS-rendered content returned empty). Apple has required two-factor authentication on Apple IDs since 2020, and third-party mail clients that cannot handle Apple's 2FA challenge flow must use an app-specific password generated at appleid.apple.com → Sign-In and Security → App-Specific Passwords; IMAP/SMTP endpoints are imap.mail.me.com:993 / smtp.mail.me.com:587. No stated deprecation timeline was found. This should be re-verified by generating a real app-specific password against a live account before committing to this path.

Route 3 — Per-Provider OAuth (full-body scopes)¶

3a. Gmail restricted scope: verification + CASA¶

Confirmed: any scope broad enough to read full message bodies (e.g., gmail.readonly, or mail.google.com if delete/permanent-delete is also needed) falls under Google's "sensitive or restricted" scope classification, which mandates the OAuth app-verification process described in Restricted scope verification and, per Security Assessment FAQ, an annual CASA security assessment performed by a Google-authorized third-party assessor (not Google itself) using the App Defense Alliance's CASA framework (appdefensealliance.dev/casa), reassessed at least every 12 months from the assessor's Letter of Assessment approval date.

Confirmed — Google does not charge for the assessment itself; developers pay the assessor directly, per Security Assessment FAQ ("Costs are negotiated directly between developers and assessors, with Google having no involvement in pricing").

Cost — conflicting figures, neither confirmed as authoritative for this exact use case: - Lower estimates, tied to CASA's newer, cheaper self-service Tier 2 tooling: $540–$1,800 for Tier 2 functional-scan validation, $4,500 for a fuller Tier 3 audit including penetration testing — see CASA Tier 2 & Tier 3 Security Review: Providers and Pricing and a first-person account citing "~$540/year even at the cheapest, TAC Security" in What I wish I'd known before touching an OAuth restricted scope. - A much higher, frequently repeated figure — $15,000–$75,000 — appears in The $50K Email API Nightmare; this is a secondary/opinion source and the figure could not be corroborated against a current CASA assessor price sheet. It likely reflects older, pre-self-service Tier 3 pricing or full-scope penetration testing engagements rather than the baseline Tier 2 assessment most small apps would need. - What would resolve the conflict: get real quotes from two or three assessors on Google's own authorized list — CASA Authorized Assessors — against WorkWingman's actual expected user count, since Google assigns Assurance Level 1 vs. AL2 based on risk factors including user count and requested scopes (confirmed from Security Assessment - Google Cloud Platform Console Help), and AL2 assessments cost meaningfully more than AL1.

Timeline: verification "can potentially take several weeks," with brand verification alone typically 2–3 business days, per Restricted scope verification. The FAQ separately cites 6 weeks as a (non-guaranteed) target for full restricted-scope verification, dependent on developer responsiveness, per Security Assessment FAQ. This is on top of, not instead of, the CASA assessment itself, whose own duration was not stated in any source retrieved in this spike (UNVERIFIED — ask a chosen assessor for a SOW timeline directly).

Recurring cost: the assessment is annual, not one-time (confirmed above), so whatever figure is chosen recurs every 12 months for the life of the Gmail integration.

3b. Microsoft Graph `Mail.Read`: publisher verification, admin consent, assessment¶

Confirmed: Microsoft's equivalent gate is Publisher Verification, not a CASA-style paid security assessment. Per Publisher verification overview: the app must be registered in a Microsoft Entra tenant (not a personal Microsoft account — apps registered under a personal MSA cannot be publisher-verified), tied to a verified Microsoft AI Cloud Partner Program (formerly Microsoft Partner Network) account, with a matching or DNS-verified publisher domain. No fee is stated for verification itself in the documentation retrieved; the practical cost is the CPP/MPN account's own eligibility requirements (which can include a minimum partner tier) rather than a per-assessment fee — UNVERIFIED for exact current CPP account cost/eligibility; would need Microsoft's Partner Center enrollment page checked directly.

Confirmed: Mail.Read (delegated) is available for both personal Microsoft accounts and work/school (Entra) accounts — see Microsoft Graph permissions reference. For personal Microsoft accounts, the signed-in user consents directly at first sign-in (no admin in the loop). For work/school accounts, organizational admin-consent policy governs whether an individual user can consent to an unverified publisher's app at all — many tenants restrict user consent to publisher-verified apps only, and Microsoft has been shifting toward requiring admin approval by default for third-party Graph apps touching Exchange/Teams content under its Microsoft-managed default consent policy (secondary-source characterization from search results summarizing Manage app consent policies and related Entra docs — UNVERIFIED in the exact current wording of that default policy; worth a direct read of that page before finalizing any org-account go-to-market claim).

Net difference from Google: Microsoft's gate is closer to a one-time (verify-once, re-verify-if-details-change) identity/domain check than an annual paid third-party penetration test. No Microsoft-equivalent of CASA (recurring paid independent assessment) was found for Mail.Read in this spike. This is the most consequential asymmetry in the whole matrix: Microsoft OAuth has lower external-assessment cost than Gmail OAuth for equivalent access. Personal-account setup friction is usually lower; org-tenant admin-consent policy can reverse that. Mail.Read remains in the same full-mailbox privacy class and requires the same consent, minimization, storage, and fail-closed UI gates. Personal Gmail (a large share of applicant mailboxes) has no IMAP app-password bridge for long once Google's 2026 phase-out (if the unverified secondary claim is correct) lands — see 2c above.

3c. Cost multiplies across providers¶

Inferred, from the confirmed per-provider facts above: because Google's CASA assessment is provider-specific, annual, and paid to a third party, while Microsoft's publisher verification is provider-specific but not an annual paid assessment, supporting Gmail + Microsoft + (eventually) other OAuth-only providers multiplies the Gmail-side cost by however many Google-equivalent programs exist, and adds Microsoft's identity/domain verification overhead on top — there is no shared cross-provider verification, so N restricted-scope OAuth integrations cost roughly N-times the Gmail-side annual assessment fee plus N-times the setup/engineering cost of implementing each provider's OAuth + token-refresh + scope-mapping logic. Yahoo and iCloud have no OAuth developer-app program comparable to Google/Microsoft's for personal consumer mail at all — Route 3 is not available for Yahoo or iCloud consumer mail as a practical matter (no public "restricted scope" OAuth application review process for third-party read access to a personal Yahoo or iCloud mailbox was found in this spike — UNVERIFIED / likely non-existent, would need Yahoo Developer Network and Apple's Sign in with Apple / MailKit docs checked directly to confirm there is truly no such program before ruling it out definitively).

Provider × Route Matrix¶

Cost and time figures are the best-available citations from this spike; entries marked "unverified" should not be quoted to stakeholders without follow-up confirmation per the notes above. "Review exposure" is the standing, recurring compliance burden, not a one-time setup cost.

Provider	Route 1: Extension DOM read	Route 2: Desktop-local / IMAP app password	Route 3: Provider OAuth (full body)
Gmail	Cost: $0 in Google fees. Avoiding OAuth/CASA when no Google API is called is inferred, not a vendor-stated extension exemption (§1a). Chrome Web Store Limited Use review, provider Terms/AUP, data minimization, and account-enforcement risk still require disposition. Time: extension review is typically days, not weeks (general CWS turnaround, not separately cited here — verify against current CWS dashboard SLAs). Chief risk: DOM instability, over-collection, provider policy, and CSP/Trusted Types on write paths (read paths lower-risk, §1c, inferred).	Cost: $0 in provider fees. App passwords work today (confirmed, §2c) but are full-mailbox credentials and a secondary source claims 2026 phase-out (unverified, conflicts with primary page). No store review does not make this low-risk: require OS-keychain storage, no cloud logging, explicit full-mailbox disclosure, revoke instructions, and product security review.	Cost: $0 Google fee + CASA assessment, conservatively $540–$4,500/yr (confirmed low end) up to a disputed $15K–$75K secondary estimate (§3a) — recurs annually. Time: verification "several weeks" (confirmed) + CASA SOW duration (unverified). Review exposure: highest of all cells — annual third-party audit, Letter of Assessment renewal, scope-minimization scrutiny.
Outlook / M365	Review exposure: same Chrome Web Store Limited Use policy as Gmail (single extension, not provider-specific). OWA-specific CSP/content-script behavior: unverified, needs a same-day DevTools check (§1d).	Not viable as a durable design: Basic Auth fully disabled org-wide already; no ongoing app-password bridge (confirmed, §2b); personal-account timeline unverified but same direction.	Cost: $0 stated fee; Publisher Verification (identity/domain check, not a paid annual pentest) (confirmed, §3b). Time: verification is comparatively fast (day-scale identity check) vs. Google's multi-week + annual audit — inferred, not independently timed in this spike. Review exposure: org-tenant admin-consent policy may block unverified-publisher apps outright (partially unverified, §3b).
Yahoo	Review exposure: same CWS/AMO/Edge policy layer as above (extension-store policy, not Yahoo-specific). Yahoo Mail CSP/content-script behavior: unverified, no incidents found (§1d).	Cost: $0. App passwords via "External connections" (confirmed mechanism, §2d); 2SV prerequisite plausible but not confirmed from primary page. No deprecation timeline found. This is a high-privilege full-mailbox credential path requiring OS-keychain storage, no cloud logging, explicit full-access disclosure, revoke/rotation UX, and product security review.	No public restricted-scope OAuth program for third-party read access to personal Yahoo Mail was found (§3c) — likely not available as a route at all; unverified/needs direct confirmation from Yahoo Developer Network.
iCloud	Review exposure: same store-policy layer; Safari's own review track is a different model entirely (App Review + Privacy Nutrition Label, not "Limited Use") (confirmed, §1e). iCloud Mail CSP/content-script behavior: unverified.	Cost: $0. App-specific passwords are the confirmed, currently-working mechanism (2FA required since 2020) (§2e, primary page not fully fetchable but corroborated by multiple secondary sources + Apple's well-documented 2FA mandate). This is a high-privilege full-mailbox credential path requiring OS-keychain storage, no cloud logging, explicit full-access disclosure, revoke/rotation UX, and product security review.	No public OAuth program for third-party read access to personal iCloud Mail was found (§3c) — Sign in with Apple does not cover Mail; not viable as a route.
Generic IMAP	N/A — not a webmail DOM to read.	Works wherever the provider still issues an app password or allows a stored password. It has no universal store-review gate, but it is a high-privilege full-mailbox credential path requiring OS-keychain storage, explicit disclosure, rotation/revocation UX, no cloud logging, and product security review.	N/A — no universal "IMAP OAuth" program exists outside each big provider's own OAuth implementation of XOAUTH2.

Recommendation¶

Candidate primary route: Route 1 (browser-extension DOM reading), scoped narrowly and evaluated provider by provider. It is not approved for implementation until provider Terms/AUP, current-markup smoke tests, and client-side minimization are dispositioned.

Rationale from the findings above: - It is the only candidate that is simultaneously free in provider fees and provider-agnostic in mechanism. Inferred: it stays outside the OAuth/CASA pipeline only while it requests no Google OAuth scope and calls no Google API; Google has not stated a DOM-reading extension exemption. - Its real, confirmed compliance burden is the Chrome Web Store Limited Use / single-purpose policy (§1b), which is lightweight compared to CASA and appears (on Google's own worked example) to permit combining "detect employer responses" and "find past recruiter conversations" as one disclosed purpose — inferred, not guaranteed, so the purpose statement should be drafted conservatively and reviewed before submission. - Its principal engineering risk is DOM fragility (unstable selectors) and unverified CSP behavior on Outlook Web/Yahoo/iCloud (§1d) — both are cheap to de-risk with a same-day DevTools spike before committing further design work. - Its policy and privacy risks remain open: provider Terms/AUP may restrict automated DOM access, and Limited Use requires client-side minimization so non-job mail is not collected or transmitted. Bulk inbox export is out of scope unless separately reviewed and disclosed.

Fallback, provider-by-provider, in priority order: 1. Gmail/Outlook — Route 3 (OAuth) as the durable fallback once/if DOM extraction proves too fragile for a given provider. Budget for Google's annual CASA cost and multi-week initial verification (§3a) as a real, recurring line item — get actual assessor quotes before committing (§3a). Microsoft Graph Mail.Read has lower external-assessment cost (§3b), but it remains full-mailbox access and keeps the same consent, minimization, storage, and fail-closed UI gates. It is the first OAuth candidate because it lacks Google's annual paid-assessment burden. 2. Yahoo/iCloud — Route 2 (app password) as the only currently-viable non-DOM fallback, since no restricted-scope OAuth program was found for either provider (§3c) and DOM behavior on both is unverified. This requires the user to manually generate and paste an app-specific password — real friction and a high-privilege credential boundary. It requires product security review, OS-keychain storage, full-access disclosure, and revoke/rotation UX even without a store review. 3. Microsoft — Route 2 is not a fallback option at all; it is already non-viable today for org tenants and trending non-viable for personal accounts (§2b). Any Microsoft path that isn't Route 1 must be Route 3.

Date impact (calendar time to a working integration), by route¶

Route 1 (DOM reading): fastest to a first isolated proof — no provider API review blocks internal testing, but product security/privacy review and provider Terms/AUP disposition still do; store review (Chrome/Edge/Firefox listing, not identity verification) is on the order of days once the extension is ready to publish, which is a publish-time gate, not a build-time one. Confidence is provisional for Gmail until a current-markup smoke test passes; selector durability remains an open maintenance risk. Confidence is lower (unverified) for Outlook Web/Yahoo/iCloud pending the DevTools spike in §1d.
Route 2 (IMAP/app password, non-Microsoft): no provider-store review is expected, but the high-privilege full-mailbox credential path cannot ship until keychain storage, disclosure, rotation/revocation, no-cloud-logging, and product security gates pass.
Route 3 (OAuth): Microsoft Graph — days to low-weeks for publisher verification, assuming a CPP/MPN account is already or can be quickly established (unverified exact duration, §3b). Google — multi-week initial verification (confirmed "several weeks"/"6 weeks" estimates, §3a) plus an annual recurring CASA assessment cycle that must be budgeted as ongoing calendar time and cost, not a one-time setup cost. This makes Gmail OAuth the slowest and only recurring-cost route in the entire matrix. Cost and calendar time are considered only after privacy, credential-handling, provider-policy, security, reliability, and fail-closed UI gates pass. Route 2 remains a high-privilege fallback, not a preferred primary.

Open items for follow-up (not resolved by this spike)¶

Live DevTools check of Content-Security-Policy headers and a minimal read-only content script against Outlook Web, Yahoo Mail, and iCloud Mail (§1d) — cheap, same-day, should happen before any further Route 1 design work on those three providers.
Direct confirmation (not secondary-source) of the 2026 Microsoft SMTP AUTH phased-rejection dates and the personal-Outlook.com Basic Auth deprecation date, by re-fetching techcommunity.microsoft.com posts with a tool that renders JS, or via curl/browser (§2b).
Direct confirmation of whether Google is actually phasing out Gmail app passwords in 2026, via the Google Workspace Updates blog, since the primary support page shows no removal date and only a secondary blog makes this claim (§2c).
Real quotes from at least two CASA-authorized assessors (appdefensealliance.dev/casa/casa-assessors) against WorkWingman's actual/projected user count, to resolve the $540–$4,500 vs. $15K–$75K cost conflict (§3a) and to get a real assessment-duration estimate.
Confirmation from Yahoo Developer Network and Apple's developer docs that no restricted-scope OAuth mail-read program exists for third-party consumer access, before permanently ruling out Route 3 for those two providers (§3c).
Provider Terms/AUP and account-enforcement review for DOM extraction on every supported webmail host. This is blocking before Route 1 can become the primary implementation.
A client-side minimization design proving that only mail needed for the disclosed job-search purpose can leave the page; whole-inbox export is not an acceptable default.