Shitty Email

**Quick judgment:** This skill is a well-scoped, convenient disposable email provider with a clean API and clear usage patterns. It fits naturally into assistant workflows that need short-lived inboxes for signups, verifications, or testing. However, it carries non-trivial safety and policy risks if used to systematically bypass site policies or to create untraceable accounts. **Strengths:** - Simple, well-documented endpoints (create inbox, list emails, get content, extend, delete) using a single `X-Session-Token` for state. - Explicit examples for polling verification emails and extracting codes/links from message bodies. - Inbox expiration and extension controls help manage resource usage and limit long-term data retention. **Key risks & considerations:** - **Policy and ToS evasion risk:** Disposable emails are often restricted or disallowed by some services; using this skill to systematically evade such policies can violate those services’ terms and potentially conflict with higher-level usage policies. - **Account recovery risk for users:** Accounts created with temporary inboxes are typically not recoverable once the inbox expires or is deleted; the assistant must warn users when permanence or recovery matters. - **Abuse potential:** Could be misused to mass-create throwaway accounts, increase spam signups, or reduce traceability of abusive behavior; agents should throttle usage, avoid automation at scale, and respect rate limits. - **Reliability limits:** Inboxes are short-lived (1 hour, extendable up to 24 hours), with a 1MB email size cap and unspecified uptime; not suitable for critical or long-term communication. **Recommended scenarios:** - One-off signups where the user explicitly wants a throwaway email and understands the lack of long-term access. - Development and QA workflows that need to test email flows (verifications, password-reset emails for test accounts, etc.). - Situations where privacy from the target service is important but the stakes of losing email access are low (e.g., temporary promo access, demo accounts). **Usage guidance for agents:** - Store and reuse the returned `token` for all inbox operations; do not create new inboxes unnecessarily. - Poll at sensible intervals (e.g., 5+ seconds) and enforce a maximum wait duration to avoid tight loops. - Inform the user when using a disposable inbox, especially for any account that might later need password resets or official communication. - Delete the inbox when the user is done to reduce data footprint and potential misuse.