Last reviewed: 25 October 2026 · Status: development draft · Operator: Marcus Waters, independent developer, operating personally (not through a registered company) · Operating jurisdiction: Arkansas, United States · Privacy and support: marcus.waters@me.com.
1. Scope and current status
Development Codename (the “Application”) is a temporary codename for a desktop email client with a Windows version under active development and a macOS version also in early development. Its final name has not been selected. Both versions are in private development; the macOS application has not been built, run or released on a Mac. The owner confirms that no external beta testers have connected real mail accounts and no real mail was accessed during development. This draft describes current evidence and intended functions; it does not claim all plans are operational.
The project website is a static information site with no account registration, contact form, newsletter, analytics script or advertising feature. GitHub Pages is operated by GitHub. Site requests may be processed under GitHub’s Privacy Statement and applicable platform terms; this project does not control GitHub infrastructure logs.
2. Mail and account data
Platform status and privacy safeguards: The current desktop implementation is Windows-specific. Development work toward macOS includes evaluation and adaptation of shared code, but a Mac-native interface, macOS secure credential storage, platform-specific data controls, and actual macOS integration and security testing have not been completed. The Windows DPAPI protection described below applies to Windows only; it does not represent an implemented Mac Keychain protection system. No Mac version is currently available to users, and macOS-specific data handling must be verified and disclosed before any Mac release.
The intended mail functions require access to data from a provider after a user chooses to connect an account and grants access. Depending on provider and enabled features, this may include account identifiers and addresses, authorization tokens or provider-specific credentials, folders and message identifiers, sender/recipient details, subjects, message bodies, attachments, read state and synchronization cursors. Provider data is needed to display and synchronize mail and carry out user-requested operations such as sending.
Current code has a Microsoft browser sign-in and mail synchronization path, but use requires the owner’s Microsoft app registration and live validation. Gmail backend work exists, but full API authorization and live testing are incomplete. Yahoo/AOL are not operational. Other providers are being evaluated; users may enter server settings for supported manual connections. Provider availability, permissions and data handling must be documented before release.
Sign-in, sending and synchronization necessarily communicate with the selected provider. The provider separately processes data under its own terms. The app is intended to cache mail locally for offline use. Its source includes an encrypted SQLite mailbox store with a database key protected using Windows DPAPI for the current Windows user. This is implementation evidence, not an independent security assessment or a guarantee against device, account, operating-system or provider compromise. The exact data stored by each feature and protection for temporary files, backups and exports still require release validation.
3. Synchronization, storage and retention
The intended sync retrieves provider mail to a local cache and applies changes during later sync. A local encrypted storage path exists in source. No project-operated hosted mailbox database or public mail-processing service is confirmed. This does not mean data never leaves the device: sign-in, sending and synchronization exchange information with the chosen provider. Future features could add processing that would require advance disclosure and consent.
Account-removal controls (implemented in Windows source with synthetic tests; live-provider behavior not independently verified): When a user removes an email account, the Application must stop synchronizing that account, remove its locally stored credentials, and delete that account's local cached messages, attachments and search indexes. Removing an account must not delete messages from the email provider's servers. Local-only unsent drafts must be preserved in a separate, locally stored Local Drafts section when their email account is removed. The user must be able to reopen and edit these drafts, export them, reassign them to a different connected email account, or explicitly delete them later. Reassignment must not send a message: drafts may be sent only through a separate, deliberate user-initiated Send action. Account removal, synchronization, reassigning a draft, beta expiry and other background processes must never automatically send or silently delete these preserved drafts. The Windows source now includes protected per-account cleanup and Local Drafts preservation, editing, export, reassignment and explicit deletion with synthetic checks. Live accounts, locked-file failures, real-provider synchronization and release build behavior still require independent testing. On the current beta-expired screen, export and explicit deletion remain available while editing and sending are blocked.
Provider authorization revocation (approved policy, with local fallback implemented in source; provider-side success not verified). Removing an account must immediately stop synchronization and other account-specific background access, clear locally held sign-in tokens, passwords or app passwords, and attempt to revoke the Application's authorization with the email provider wherever that provider supports revocation through an available and authorized mechanism. Local cleanup must proceed even if the remote request is unsupported, fails or has an uncertain outcome. The Application must clearly distinguish a confirmed provider-side revocation from local sign-out, an attempted or failed revocation, and an unsupported revocation. If remote access cannot be confirmed revoked, it must tell the user and give provider-specific instructions for reviewing and removing the Application's access in the provider's security or connected-app settings; for app-password connections this may require the user to revoke that app password through the provider. Removing an account must never delete messages or other data from the provider's servers. Any preserved Local Drafts must remain available and must never be sent automatically. Current Windows source reports remote revocation as Unsupported for the active Microsoft adapter and manual IMAP/app-password connections and presents provider-specific manual guidance; it does not claim to have revoked access remotely. Where future providers offer supported app-grant revocation, that path and truthful status reporting must be tested before release.
Connected-account cache retention (approved policy; enforcement requires verification). For Gmail, Outlook, Hotmail, and other non-Yahoo mail accounts, the Application is intended to retain locally cached messages and attachments while the account remains connected, supporting offline access. Synchronization must reflect provider-side message changes and confirmed deletions, and removing an account must clear that account's cached mail as described above. Any shorter retention or deletion rule required by a provider takes precedence. This decision does not override local-only draft preservation or provider-specific limits.
Local technical diagnostic logs (approved design; not yet verified). Ordinary technical logs, if stored by the Application, must stay on the user's device and be automatically deleted within seven days of creation. They must be sanitized to exclude mailbox content, credentials, account identifiers and identifying file paths. Such logs must not be uploaded automatically. Their retention and cleanup must be implemented and tested before this policy is finalized. This is separate from the default-off, explicit-opt-in encrypted crash-report queue and from the 30-day limit on reports received by the developer.
Message and draft exports (source-implemented in the Windows development branch; live/platform qualification pending). The current source defaults to a password-protected .upx (UPIGEON1) encrypted file when a user explicitly exports an available message as text or a Local Draft as JSON. A user chooses and confirms an export password; opening it requires re-entry. The source derives an encryption key using PBKDF2-HMAC-SHA256 and protects the content with AES-256-GCM. It does not deliberately save or upload the password; transient runtime copies cannot be guaranteed forensically erased. The application warns that a forgotten password can make the export unrecoverable. Choosing a supported unencrypted TXT/JSON export instead requires deliberate format selection and a separate privacy warning; encryption failure must never silently produce plaintext. The source includes an independent Python reference reader successfully tested with synthetic data, but real save dialogs, a polished in-app import/open workflow and Windows/macOS interoperability still need qualification. EML export is not confirmed as implemented. The user controls where the exported file is stored, shared and deleted, and the Application must not silently alter, delete, send or upload it. This source evidence is not a claim that an independently audited or publicly released version is available.
Temporary export files (future safeguards; no separate staging file in current encrypted-export source). The Application must protect any application-created export staging or temporary working files, including those used to prepare a portable encrypted export or a user-selected plaintext export. It must delete its own temporary export files immediately when an export completes successfully or fails. After an unexpected shutdown or interruption, it must identify and remove any abandoned application-owned export staging files at the next application launch. Temporary export data must never be uploaded or transmitted automatically, and no export password may be written to these files. Cleanup must be limited to files that the Application can reliably identify as its own temporary staging data; it must never delete or modify the user’s completed export or other user-managed files. Deletion cannot guarantee erasure of copies retained by the operating system, storage hardware or external backups. The existing encrypted-export source writes without a separate export-staging file; any future staging or plaintext temporary workflow must comply with these controls and be tested. This is not a claim of secure erasure from storage hardware.
Optional encrypted local backups (approved design; not yet implemented or verified). The Application may offer user-enabled, application-managed encrypted local backups of eligible cached mail and locally stored drafts, including preserved Local Drafts. This feature must be off by default; connecting an account, enabling AI or opting in to crash reporting must not activate it. The Application must not automatically upload or synchronize backups to any online service, send them to the developer, or require paid hosting, subscriptions or other paid services. A user may separately choose to move a backup, and operating-system or third-party backup/sync behavior outside the Application's control must not be presented as an Application upload. Backups must protect their contents and must not include mailbox passwords, authentication tokens or other stored credentials. Backup eligibility must be enforced per mail provider and per type of record; if a provider's data-retention or security requirements cannot be satisfied, that data must be excluded and backup creation must fail safely if correct exclusion cannot be guaranteed. Under the current Yahoo-specific policy, Yahoo-downloaded mail data (including remote messages, headers, attachments and indexes) is not eligible for these backups. Locally composed drafts must remain preserved without granting an exception to copy restricted provider data. Before implementation or activation, the Application must establish and test backup retention limits, rotation, encrypted recovery, key handling, removal of expired or provider-restricted data, cleanup after account removal and permanent message deletion, safe restoration, and user controls for disabling backups and deleting application-managed copies. User-created portable exports are separate and remain under the user's control. Deleting an application-managed backup cannot guarantee erasure of operating-system snapshots, copied files or third-party backups.
Manual backup creation only (approved design; not yet implemented). Enabling optional encrypted local backups must make a Back Up Now action available, but must not itself create a backup. The Application must create a new application-managed backup snapshot only after the user deliberately selects Back Up Now for that snapshot. It must never create snapshots automatically on a schedule, at startup, during mail synchronization, following account connection, or because other app features are enabled. Backup creation must not silently upload data or activate a paid service. This manual-only rule does not prevent the Application from automatically expiring, rotating, invalidating, or deleting existing managed snapshots when required by the three-snapshot/seven-day limits, a shorter provider rule, account removal, or permanent message deletion. Yahoo-downloaded restricted data and other ineligible records must still be excluded. The user’s own portable exports remain independent and are never removed by managed-backup maintenance. The button, consent flow, secure snapshot creation, and cleanup behavior require implementation and testing before any public availability.
Encrypted backup retention (approved design; not yet implemented). If the user enables application-managed local backups, the Application must retain no more than three encrypted backup snapshots, with each snapshot kept for no longer than seven days after its creation. The earlier of these limits controls: when a fourth snapshot is created, the oldest must be removed; snapshots reaching seven days must expire even if fewer than three exist. A provider-specific restriction requiring shorter retention takes precedence. Yahoo-downloaded restricted mail data must remain excluded entirely, irrespective of backup age or encryption. The Application must enforce these limits during normal operation, when creating backups, and on startup before allowing a backup to be read or restored; if the device or Application is not running at an expiry time, cleanup must occur at the next launch, not be represented as having happened while the Application was stopped. When an account is removed or a message is permanently deleted, affected application-managed snapshots must be removed or safely rebuilt so that prohibited content cannot remain accessible or be restored. If safe selective removal cannot be verified, the affected snapshot must be deleted and restoration blocked rather than preserve or reintroduce restricted data. Backup cleanup must never remove or modify files that users explicitly exported and control. Exact deletion, encrypted restoration, expiration and failure behavior still require implementation and testing; deleting local snapshots cannot guarantee erasure of copies retained by the operating system, hardware or external backup systems.
Local Recovery for encrypted backups (approved design; not yet implemented or verified). Opening an eligible, unexpired application-managed encrypted backup must first present recoverable mail and locally composed drafts in a separate, protected Local Recovery area rather than immediately merging content into an existing mailbox or the protected Local Drafts section. Before displaying recovered content, and again before any selective restore, the Application must verify backup integrity and eligibility, including the three-snapshot/seven-day limits, any shorter provider-specific limits, account-removal status, and records that have been permanently deleted. Expired backups, permanently deleted messages, Yahoo-downloaded restricted data, other provider-ineligible records and records with insufficient evidence of eligibility must not be displayed for recovery or restored. Users must be able to review eligible items and explicitly select which to restore locally; existing mail and drafts must never be silently overwritten or removed. Recovery must not automatically send a message, restart an outgoing draft, change provider-side mail, reconnect an account, or upload data. If validation fails or a backup becomes ineligible during review, affected items must be blocked and the user informed. User-created portable exports remain separate and must not be deleted by backup recovery or maintenance. Protected preview storage, session cleanup, and conflict handling have approved requirements below but remain unimplemented and untested. This describes a planned feature only; no Local Recovery area or application-managed backup restore is verified as operational.
Conflicts during Local Recovery (approved design; not yet implemented). When an eligible recovered email or draft conflicts with a locally existing item, the Application must show both the current and recovered versions for comparison, and require the user to explicitly choose either Keep Both or Replace Existing. Keep Both must preserve the original and create a separately identifiable, clearly labeled local recovered copy. Replace Existing must require an additional, separate confirmation identifying the item to be replaced; cancellation, closing the dialog or declining confirmation must leave all existing and recovered data unchanged. A confirmed replacement may change only the specifically selected eligible local item. Neither choice may silently overwrite another message or draft, schedule or send a message, reconnect an email account, initiate synchronization of the recovered copy, write to provider-side mail or upload any recovery content. Before displaying, comparing and committing either choice, the Application must check that the backup and item remain eligible; expired, permanently deleted, removed-account-ineligible, Yahoo-downloaded or other provider-restricted data must never be recovered by either route. If local-only replacement cannot be guaranteed for a provider-synchronized item, replacement must be blocked rather than risk a server change. Completed user-created exports remain untouched. The comparison, confirmation, conflict resolution and safety checks still require implementation and testing; this is not an existing application capability.
Local Recovery temporary-data cleanup (approved design; not yet implemented). The Application must protect Local Recovery previews and any application-managed staging data while a recovery session is open. It must discard and delete all application-owned temporary recovery previews and staging as soon as the user finishes, cancels or closes the session, without retaining a reusable copy after the session. After a crash or interruption, it must identify and clean up abandoned recovery staging at the next application launch before making any such data accessible. Recovery content must never be automatically uploaded, transmitted, emailed, synchronized to an email provider or used to send messages. At every preview and restore action, recheck the snapshot’s age, provider restrictions, account-removal state and permanent-deletion status; if the source becomes ineligible, block access and remove its temporary preview data. Cleanup must be limited to identified application-owned temporary recovery data and must not delete or modify any still-eligible original encrypted backup snapshot, successfully restored local item or user-created portable export. The original backup remains subject to its independent three-snapshot/seven-day expiry and deletion requirements, and external operating-system snapshots cannot be guaranteed erased. Implement and test this rule before enabling Local Recovery.
Encrypted backup password and key recovery (selected final design; not yet implemented). Each user-requested application-managed encrypted backup must be protected by a user-chosen password that the user confirms when creating the snapshot and re-enters when opening or restoring it. The Application must not store, retain, transmit, upload, log, synchronize or recover backup passwords for users; only transient processing needed to encrypt or decrypt an eligible snapshot is permitted. The Application must warn before backup creation that a lost or forgotten password can make the snapshot permanently unrecoverable and that the developer cannot reset it. The protected backup format, key-derivation method, integrity checks and independent recovery testing must be specified and verified before release. Backup passwords are distinct from mailbox passwords and must never grant access to or be backed by provider credentials. This requirement does not claim that the future managed-backup format is implemented or compatible with the existing user-created portable export format.
Disabling encrypted local backups (selected final design; not yet implemented). When a user turns off optional application-managed backups, the Application must clearly warn that all existing application-managed backup snapshots will be removed and request a separate confirmation. If the user cancels, the setting and existing eligible snapshots remain unchanged. If confirmed, the Application must stop new backup creation and immediately delete its managed snapshots and temporary backup staging, including recovery previews associated with those snapshots; it must never erase stored mail, preserved Local Drafts, provider-side mail, successfully restored items or user-created portable exports. If cleanup is blocked, the Application must report the failure, prevent use of affected snapshots and securely retry at the next launch; it must not falsely claim deletion while files remain. Re-enabling backup does not recreate anything automatically: a new snapshot still requires an explicit Back Up Now action. Provider data restrictions and mandatory expiry/deletion safeguards apply whether backups are enabled or disabled. The controls and cleanup behavior require implementation and testing.
Other retention and cleanup remain under review. Preserved Local Drafts are intended to remain available until the user explicitly deletes them; their storage and recovery behavior must be tested. Retention periods and cleanup rules for database journals and non-export temporary files remain under review. The encrypted-backup snapshot, manual creation, password-loss, disabling, preview-cleanup and recovery-conflict policies have been selected, while their implementation, independent testing, and technical enforcement remain incomplete. The newly approved export-staging cleanup requirements still need implementation and verification. User-created exported files remain under the user’s control as described above. Windows token-cache cleanup and confirmed provider-side authorization revocation, fallback guidance and consent-removal handling still require implementation verification. Provider copies and backups are governed by that provider. These behaviors must be confirmed before this becomes a final policy.
Yahoo-specific 12-hour cache policy. Yahoo Mail is excluded from the connected-account retention policy above. The developer has directed that locally cached Yahoo mail data expire no later than 12 hours after each item's retrieval, including local message content, attachments and indexes, without deleting mail from Yahoo's servers. The Windows source and synthetic checks implement a process-memory-only Yahoo message cache with a maximum twelve-hour item lifetime, clearing downloaded content on restart/exit and avoiding new durable Yahoo message/attachment/index copies. Protected connection metadata, synchronization cursors, folder identities and minimal queued read-state locators may persist; their treatment under Yahoo's rules still needs written clarification. Live Yahoo access, independent security review, and platform/storage-copy limitations remain unverified. Yahoo's published developer API terms and guidelines generally restrict retaining Yahoo user data beyond 24 hours unless an exception or applicable agreement provides otherwise; a 12-hour local cache alone does not establish compliance or grant access. The Application does not currently have approved or operational Yahoo/AOL Mail OAuth access. The applicability of Yahoo's retention rules to native desktop IMAP/SMTP access and any provider-specific conditions still requires confirmation from Yahoo. See Yahoo Developer Access and Yahoo API Terms.
4. Optional AI-assisted advanced spam detection and removal
Limited purpose of AI integration. The Application's planned AI integration is exclusively for advanced spam detection and spam-removal assistance, including evaluating suspected junk, phishing, impersonation and fraudulent messages as possible spam. AI is not intended to compose or send mail, manage accounts, change synchronization or other ordinary email functions, or make unrelated mailbox decisions. AI provides an advisory assessment of suspected spam; it has no authority to delete, move or otherwise modify messages, and its output alone cannot authorize removal. Any future automatic spam removal must be separately enabled by the user and carried out by application-controlled, deterministic rules with validated high-confidence criteria, safe-sender protections and review of uncertain cases. AI failure or absence must not interfere with ordinary email operations.
Current development status. The application currently provides only an unassessed security-review simulation. A working AI model integration, advanced spam analysis, automatic spam filtering and permanent spam removal have not been activated or independently validated. No mailbox content is currently transmitted to an external AI service. Future external AI analysis, where permitted by the applicable mail provider, requires an explicit user choice and disclosure of the selected content, destination and purpose; enabling spam detection does not automatically authorize a cloud upload.
No Yahoo API data is currently sent to, or proposed for transfer to, a third-party AI or cloud provider. Yahoo API data must not be assumed shareable with a third party. Any future proposal involving Yahoo data must first be checked against Yahoo’s then-current developer requirements; if third-party transfer is prohibited, that processing must not be implemented. For any provider whose rules permit external analysis, the exact content, recipient and purpose would need to be disclosed and user-enabled before use.
Yahoo service, third-party processing and consent (future authorized connections only). If Yahoo authorizes the Application and a user deliberately connects a Yahoo account, Yahoo remains the independent third-party email service and processes sign-in, OAuth consent, IMAP/SMTP requests, network identifiers and messages on Yahoo-controlled systems under its own privacy terms. The user controls authorization through Yahoo’s consent and account-security settings. The Application will request only the approved mail permissions needed to read, send and manage the user’s own mail; no Yahoo user mailbox contents are intended for a developer-operated server, analytics platform, external AI provider or automatic backup service. The static project website is separately hosted by GitHub Pages, which can process website request data under GitHub’s privacy terms. The exact authorized Yahoo scopes, data retention for persistent minimal metadata and consent wording require approval and live verification before these statements can become a release policy.
Yahoo’s developer requirements call for accurate disclosures about collection and use of Yahoo API data, user controls, security standards and consent for each use case. Yahoo is not operational in the Application at present. Any future Yahoo access request, requested permissions and described use cases must match the Application’s actual current and specifically planned functionality; a request must not claim capabilities that do not exist or are not planned. The proposed use case and final privacy disclosures must be reconciled with the actual product behavior before any Yahoo API submission.
5. Diagnostics and reporting
Local logs are not crash-report uploads. Ordinary technical logs stay on the device, are not uploaded automatically and expire within seven days. They are separate from the encrypted crash-report queue, which requires explicit opt-in and has its own local pending-report expiry; developer-received reports retain their previously approved 30-day limit.
No general application analytics, crash-reporting or diagnostic-reporting service is confirmed as deployed. Source includes an optional path for submitting limited, allowlisted public mail-server settings (domain, server hosts, ports and encryption modes), only when an owner-configured HTTPS endpoint and enrollment credential exist. The owner confirms no such endpoint has been deployed or used. The report payload excludes message content and mailbox credentials.
Planned optional crash and diagnostic reports (not yet operational). The Application is intended to offer automatic transmission of sanitized diagnostic and crash reports only after the user explicitly opts in; the setting must be off by default and users must be able to disable it. The only approved report fields are the Application version, Windows version, error code, error timestamp and sanitized crash stack traces. Stack traces must exclude identifying local file paths, usernames, email addresses, account or device identifiers, message content and other personal or secret data. Reports must never contain mailbox data (including message headers, subjects, bodies and attachments), passwords, app passwords, authentication tokens or other credentials. Reports must be assembled from a strict allowlist, sanitized before transmission, and independently tested with representative and adversarial crash data to confirm that forbidden information is not exposed. If sanitization fails or cannot be verified, automatic transmission must not occur. Adding any further report fields requires updated disclosures and review before activation. The approved retention policy requires that diagnostic and crash reports received by the developer be kept for no longer than 30 days after receipt and then automatically deleted from developer-controlled systems, including any developer-controlled backup copies where technically feasible. If applicable law requires preserving a specific report for longer, only that report may be retained for the legally required period and must be deleted once that obligation ends. No broader retention exception is authorized. The selected destination is an owner-controlled HTTPS receiver implemented using a Cloudflare Worker, which will validate and route approved crash reports into categorized issues in the developer's private GitHub repository (not the public project website). This is not an email-reporting system: reports are never sent from a user's mailbox, and no email sender address or provider-mail authorization is used. The same Worker also has a separate route for user-provided public IMAP/SMTP server-settings candidates, which are never mixed with crash data. GitHub crash issues use the report:crash label and a logical title resembling crashreport-xxxx.txt; provider-settings issues use report:provider-settings and providersettings.txt. These names do not represent files committed into permanent Git history. No Worker endpoint, D1 database, crash reporting receiver or GitHub issue publication is deployed or enabled at present. Before activation, the Worker must enforce TLS, strict server-side field validation, bounded requests, abuse limits, restricted administration and tested deletion procedures. Cloudflare and GitHub will process submitted reports and may process incidental transport metadata, such as connection IP addresses and platform logs; their infrastructure and retention policies are relevant to this design. The precise public HTTPS receiver address, credentials, any service-specific logs and deletion verification remain outstanding. GitHub's issue-deletion capability must be tested so developer-received reports are removed within 30 days, but infrastructure backups, notifications and other copies outside the developer's control cannot be promised erased. Accurate processor disclosures, user opt-in, end-to-end tests and approval remain required before any automatic report is transmitted. These details and the user's informed opt-in are required before any reporting is activated. This is a design requirement, not a claim that automatic deletion or a reporting service is operational. Choosing this design does not mean automatic reporting currently runs or that production sanitization has been tested.
6. Sharing and security
The application is not intended to sell mailbox data or use it for advertising. Mail data is exchanged with the provider selected by the user for requested mail functions. No other third-party recipient of mailbox content is currently confirmed. This is not permission for future external processing; recipients and purposes must be reviewed and disclosed before use. In particular, this draft does not authorize or imply third-party transfer of Yahoo API data.
Development includes a local encrypted mailbox store and a key protected for the current Windows user. Microsoft sign-in uses a provider-hosted browser flow; supported manual credentials are intended to be protected separately from the ordinary mail database. These controls are not independently certified, and live-account validation is incomplete. Do not send passwords, tokens, private keys or mail content to the project through this website.
7. Choices, requests and changes
Account connection is intended to be user initiated. The approved account-removal behavior is described in Section 3; the actual controls, their cleanup results, and any export features and privacy-request handling remain to be verified. Provider-side app authorization revocation must be attempted where supported; where unavailable, unsuccessful or uncertain, the user must be told clearly and provided with provider-specific instructions to revoke access manually. Removing a local account must never be represented as confirmed provider-side revocation without verification. For privacy questions, requests about account data, and general application support, contact marcus.waters@me.com. The remaining data-control procedures must be verified before this policy is finalized. Users may also use their provider’s privacy and account controls.
The Application is intended for users aged 13 and older and is not directed toward children under 13. People under 13 should not use the Application or send personal information to the published privacy and support contact. If you believe a child under 13 has provided information directly to the developer, contact marcus.waters@me.com so the concern can be reviewed and handled as required by applicable law. Age verification or enforcement within the Application has not yet been independently verified. A dated final policy and verified data-control procedures are still needed before general release.
Outstanding release verification — no further privacy design choices pending
The developer has selected the current backup, recovery, local logging, export, removal and consent policies. The checks below are technical, operational, provider-approval and owner/legal review requirements, not a request to make more optional product-design choices. Features that are only planned must not be represented as deployed. Complete and verify the relevant checks before public release or submitting this policy as a final Yahoo developer-registration disclosure.
- Complete provider-by-provider data inventory, exact scopes, Yahoo API purpose and consent wording; confirm that any requested Yahoo access and use case match actual current and specifically planned functionality.
- Independently validate the Windows-source account-removal, credential cleanup, Local Drafts preservation and manual provider-revocation guidance with authorized real-provider accounts and release builds. Provider-side revocation must not be claimed where Unsupported; Yahoo/AOL remains unauthorized. Confirm local storage, cache and provider retention rules with live testing.
- If future export or recovery operations create temporary staging, enforce protected storage, immediate session cleanup and next-launch interrupted-file cleanup, no credential leakage or automatic uploads, and strict separation from user-owned exports; verify against partial writes and locked-file failures. Current encrypted-export source reports no separate staging file.
- Independently qualify the source-implemented default encrypted .upx exports and deliberate plaintext warnings using real save/open dialogs, synthetic adversarial files, password-loss cases, and actual Windows/macOS compatibility tests; EML and in-app import are not yet verified. Protect user-created exports against background deletion or upload.
- Implement and test seven-day automatic cleanup of sanitized, local-only technical logs, including restart handling. Exclude mailbox content, credentials, account identifiers and identifying paths. Never automatically upload these logs, and keep the opt-in crash-reporting rules separate.
- Implement and test Local Recovery conflict handling: compare eligible existing and recovered message/draft versions side by side, then require an explicit Keep Both or Replace Existing choice. Keep Both preserves the original and adds a distinct, clearly labeled local recovered copy; Replace Existing requires a separate confirmation and changes only the selected eligible local item. Cancel or close must preserve all existing items. Validate no silent overwrite, no sending or queued sends, no provider-side writes or synchronization, and strict eligibility rechecks immediately before commit. Deny replacement when local-only safety cannot be established; block expired, deleted and provider-restricted data, including Yahoo downloads, for both choices.
- Implement and test Local Recovery preview cleanup: immediately discard application-owned previews and staging when the user finishes, cancels or closes; clear abandoned recovery files at the next launch after an interruption; do not upload, send or sync previews; recheck eligibility throughout recovery. Preserve still-eligible source backups, restored local items and user-created exports, subject to independent mandatory snapshot expiry/deletion.
- Implement and test password-protected managed backups using a user-chosen and confirmed password per backup, password re-entry for restore, zero persisted/transmitted passwords and a clear lost-password/no-developer-recovery warning. Validate encryption/integrity, incorrect passwords, safe failure and cross-device limitations before release.
- Implement and test turning optional managed backups off: separate warning and confirmation; cancel preserves the setting and eligible snapshots; confirmation stops new creation and deletes app-owned snapshots and staging without touching mail, Local Drafts, restored items or user exports. Show and retry partial deletion failures at startup, block invalid snapshots, and never claim deletion without confirmation; re-enabling requires a new explicit Back Up Now action.
- Implement and test the separate Local Recovery area for eligible application-managed encrypted backup contents. Verify backup authenticity and allowed data before preview and again before each explicit local item restoration. Require user review and item selection; never automatically merge or overwrite mail/drafts, send messages, reconnect accounts, alter provider-side mail or upload content. Block expired, permanently deleted, removed-account and provider-restricted data, including Yahoo-downloaded mail, even during an active recovery session. Validate conflicts, staging cleanup, errors and mid-session eligibility changes; user-controlled portable exports must remain untouched.
- Implement and test the approved backup-retention limits: at most three encrypted application-managed local snapshots and no snapshot older than seven days, whichever limit is reached first; apply shorter provider deadlines and completely exclude Yahoo-downloaded restricted data. Test expiration and count rotation during operation and before access at next startup, account-removal and permanent-message-deletion cleanup, invalidation of affected snapshots when reliable selective removal is impossible, and rejection of restorations that would reintroduce prohibited data. Never delete user-created portable exports. This is a required future acceptance gate, not an implemented feature.
- Implement and test manual-only backup creation: the feature remains off by default, and enabling it must not create any snapshot; only an explicit Back Up Now selection may initiate a new encrypted snapshot. Verify there is no scheduled, startup, sync-triggered or account-connect-triggered snapshot, while automatic age/count rotation, removal of restricted content and invalidation after account removal or permanent deletion still occur. Keep existing privacy and provider restrictions and do not touch user-created exports.
- Design and test optional encrypted application-managed local backups of eligible mail and drafts, disabled by default, with no automatic online upload and no paid service requirement. Exclude Yahoo-downloaded and any other provider-restricted data unless the applicable requirements can be proven satisfied. Specify retention/rotation, secure recovery, encryption-key handling, user opt-out and deletion, account-removal and permanent-deletion propagation, restored-data filtering and failure-safe cleanup before activation. Do not confuse backups with user-created portable exports or promise removal of external copies.
- Yahoo's written clarification or specifically applicable agreement regarding the default API data-retention rule and local IMAP/SMTP offline caching, including any required technical limits.
- Implement and verify the approved default-off, explicit-opt-in automatic crash/diagnostic reporting design. Implement and test the approved field allowlist (Application version, Windows version, error code, timestamp, sanitized stack traces), exclusion of mailbox content, credentials, identifiers and identifying paths, the planned Cloudflare Worker to private GitHub Issues transport (no deployment or credentials configured), distinct `/v1/crashes` and `/v1/providers` schemas and labels, strict TLS/size/rate limits, separate enrolled client credentials, GitHub 30-day issue deletion (with narrowly applicable legal preservation exceptions), Cloudflare/GitHub data processing, opt-out, and security testing before activation. The existing unused public-server-settings reporting path remains separate.
- Verify that the optional AI integration is restricted to advanced spam detection and removal assistance only, remains advisory without destructive mailbox permissions, and cannot approve deletion on its own. Validate separate user authorization and deterministic safeguards before any spam removal is enabled. Confirm any future AI provider, data sent, user controls and compatibility with provider terms. Live AI and automatic spam deletion are not currently available; Yahoo API data is not proposed for third-party AI/cloud processing.
- Independent validation of encryption, credential protection, logging and production security. Before any macOS release, separately verify the Mac-native interface, Keychain or equivalent OS-protected secrets, encrypted storage, local data controls, provider sign-in, distribution and applicable platform-specific disclosures.
- Operator is Marcus Waters, an individual independent developer, not a registered business. The operating jurisdiction is Arkansas, United States; the intended minimum user age is 13. The final product name still requires owner confirmation. The privacy and support email contact has been supplied for publication.
Yahoo API registration: Yahoo requires accurate public disclosures of data use, controls, security and consent. This draft is not ready for registration. Any requested Yahoo API access and use case must match the Application’s actual current and specifically planned functionality. Submit only after final policy and live behavior are reconciled and owner-approved.
This working document is not legal advice. Obtain qualified legal review before general availability.