Skip to content

What recruiter mail access can and cannot do (WING-380)

Technical companion: Mail access route research.

Current product truth

Work Wingman has ranking and parsing domain groundwork, but no mailbox producer and no user-facing way to supply mail. This integration does not yet connect to Gmail, Outlook, Yahoo, iCloud, or an IMAP mailbox. The Recruiter Reactivation screen therefore shows an explicit unavailable state instead of claiming that it searched a mailbox. It never invents contacts, threads, or employer matches.

The Calendar and manual application-status screens use their own existing application data. They do not prove that inbox extraction exists. Draft helpers remain copy-only unless a separate feature explicitly says it can send.

Why reading recruiter mail is difficult

Recruiter identity and intent often appear only in the message body. Sender and subject metadata are not enough for reliable extraction. Reading full bodies creates a sensitive-data boundary, so the app needs a route that users understand and providers permit.

The technical spike compared three routes:

  1. A browser extension reads the visible mail page in a session the user already opened.
  2. The desktop app reads a local mail store or connects with a user-created app password.
  3. Work Wingman asks each provider for OAuth permission to read message bodies.

None is universally available. Browser-page reading avoids a provider mail API but still requires provider Terms/AUP review, clear extension-store disclosure, strict client-side minimization so non-job mail is not collected, and durable selectors. Local stores and app passwords cover only some providers and account types. Reading a local mail store is also full-mailbox content access; it needs explicit disclosure, minimization and retention limits, no cloud logging of message bodies, product security review, and a fail-closed UI before any mailbox claim. App passwords and stored mailbox passwords are full-mailbox credentials, not limited job-mail scopes. They remain high-privilege even without store review and need keychain storage, explicit full-access disclosure, revoke/rotation UX, and product security review before any ship decision. Full Gmail API access can require restricted-scope verification and recurring security assessment. Microsoft Graph Mail.Read is also full-mailbox access; it uses a different publisher-verification and tenant-consent model, not a smaller privacy boundary.

Before enabling any mailbox claim, test a read-only extension against current Gmail and Outlook Web markup in an isolated account, document exactly which text leaves the page, and prove that a markup change fails visibly. Yahoo and iCloud need the same hands-on check before support is promised. Provider OAuth or app-password work should remain separate, explicit integrations.

Until one of those producers passes its privacy, credential-handling, provider-policy, security, reliability, and fail-closed UI gates, the UI must keep the unavailable message. The domain ranking code is useful backend groundwork; it is not evidence that a mailbox has been connected.