Ви відкрили тимчасову скриньку, отримали те, що було потрібно, і тепер запитуєте себе: а що насправді станеться, коли мине 7 днів? Можливо, ви розробник і хочете розібратися в системі, перш ніж використовувати її для тестування. Можливо, ви дбаєте про приватність і хочете точно знати, що означає завершення строку. У будь-якому разі ось повна й чесна відповідь.
Коротко: усе видаляється назавжди. Адреса, сеанс, кожен лист у скриньці — усе це прибирається з бази даних після завершення строку. Не архівується. Не анонімізується й не зберігається для аналітики. Не видаляється «м’яко» з прапорцем, який можна скасувати. Видаляється — тобто записів у базі більше немає. Немає жодного «кошика» і жодних резервних копій, які дали б змогу будь-кому, зокрема й нам, повернути ці дані.
Якщо вам потрібно було знати лише це — відповідь ви отримали. Але якщо хочете зрозуміти логіку, точний технічний графік і що це означає на практиці для різних сценаріїв, читайте далі.
Чому автовидалення — це перевага, а не обмеження
Перша реакція більшості людей — сприймати завершення строку як обмеження, як щось, що в них забирають. Здається, ніби йде зворотний відлік до втрати доступу. Але насправді це центральна особливість сервісу тимчасової пошти, і саме вона робить гарантію приватності реальною, а не теоретичною. Дані, які не зберігаються, не можна зламати. Їх не можна продати. Їх не можна витребувати через суд. До них не дістанеться ображений працівник чи надто цікава третя сторона. Ніхто не зможе ними скористатися для будь-чого після завершення сеансу.
Порівняйте це зі старим непотрібним акаунтом у якомусь сервісі, де ви зареєструвалися багато років тому. Цей акаунт — разом із вашою адресою, історією користування й усім іншим, що там зібрали, — залишається мішенню ще довго після того, як ви про нього забули. Кожен витік даних, про який пишуть у новинах, стосується даних, які зберігали й так і не видалили як слід. Troy Hunt, дослідник безпеки, що створив Have I Been Pwned, за ці роки задокументував тисячі витоків, що зачепили мільярди записів. Закономірність завжди та сама: компанії збирали дані, тримали їх значно довше, ніж потрібно, і зрештою ці дані опинялися у відкритому доступі. Архітектура TempEmail.ai робить цю категорію проблем структурно неможливою для вашої тимчасової скриньки — бо даних, які можна зламати, просто немає.
7-денний строк — свідоме інженерне рішення, що врівноважує вашу приватність і практичну зручність. Для переважної більшості сценаріїв — отримати лист підтвердження, протестувати реєстрацію, отримати посилання на завантаження, завершити реєстрацію — 7 днів більш ніж досить. Навіть щедро. Більшість цих задач займає хвилини, а не дні. Строк існує, щоб дати вам комфортний запас — час повернутися по пізнє підтвердження чи наступний лист, — а не щоб безстроково зберігати ваші дані.
Точний графік
Ось що саме відбувається крок за кроком — від моменту, коли ви відкриваєте сеанс, до моменту, коли ваших даних більше немає:
- Ви відкриваєте TempEmail.ai — створюється новий сеанс з унікальною адресою та часом завершення через 7 днів після створення, що зберігаються в базі даних.
- Протягом цих 7 днів листи надходять у реальному часі через живе WebSocket-з’єднання. Ви бачите їх у браузері миттєво, без оновлення сторінки. Кожен лист зберігається з власним строком: 7 днів із моменту надходження.
- Коли минає 7 днів, сеанс і скринька позначаються в базі як прострочені. Нові листи на цю адресу більше не доставляються.
- Автоматично запускається фонова задача очищення. Під час кожного запуску вона назавжди видаляє всі листи, яким минуло 7 днів, а також усі прострочені сеанси й адреси, до яких більше не прив’язано листів.
- Щойно вашому останньому листу мине 7 днів і пройде очищення, усі сліди вашої скриньки повністю зникають із бази даних.
«Видалено назавжди» тут означає, що записи в базі даних повністю видаляються. Їх не видаляють «м’яко» з прапорцем. Не переносять в архівну таблицю. Не зберігають безстроково в резервних копіях. Записи прибираються з робочої бази. Це не обіцянка, яку ми даємо неохоче, — у цьому весь сенс дизайну системи.
Іншими словами, тут два годинники. Скринька живе 7 днів із моменту створення, а кожен лист — 7 днів із моменту надходження. Тож лист, що надійшов в останній день життя скриньки, зберігається трохи довше за саму скриньку — але ніколи не довше 7 днів від надходження — і видаляється задачею очищення, щойно цей строк мине.
Що буде з листами, які прийдуть після завершення строку
Якщо хтось — чи якась автоматична система — надішле лист на вашу тимчасову адресу після завершення її строку, лист буде відхилено. Адреси більше немає в системі, тож доставляти його нікуди. Поштовий сервер відправника отримає повідомлення про невдалу доставку (bounce), точнісінько як тоді, коли лист надсилають на будь-яку неіснуючу адресу на будь-якому поштовому сервері світу. Для відправника це нічим не відрізняється від надсилання на адресу, яка ніколи не існувала.
Це варто мати на увазі під час тестування. Якщо ви використовуєте адресу тимчасової пошти, щоб протестувати відкладені сповіщення — наприклад, застосунок, що надсилає лист через кілька годин після реєстрації, чи серію листів, яка надсилає наступний лист назавтра, — ці листи надійдуть нормально, якщо їх надіслано протягом 7 днів життя скриньки. Повернуться лише листи, надіслані після завершення строку адреси. Якщо вашому тесту потрібно отримувати листи поза цим проміжком — скажімо, нагадування через три тижні після реєстрації, — для цієї пізнішої фази тесту доведеться відкрити нову скриньку або підлаштувати таймінг тесту під 7 днів.
Чи можна продовжити сеанс?
Ні. Коли строк скриньки сплив, її не можна продовжити, поновити чи відновити. Даних немає. Так задумано: якби сеанси можна було продовжувати безкінечно, гарантія приватності втратила б сенс. Фіксований ліміт у 7 днів і робить систему надійною: ви точно знаєте, що ваші дані буде видалено, бо система не допускає винятків.
Якщо ваша скринька ще активна й ви хвилюєтеся, що час спливає, важливо розуміти: таймер сеансу відраховується від часу створення, а не від вашої останньої активності. Годинник почав іти, коли ви вперше зайшли й створили сеанс. Переходи всередині скриньки, читання листів чи оновлення сторінки не скидають і не продовжують таймер. Строк фіксований — рівно 7 днів від створення.
Якщо адреса потрібна довше — наприклад, для тесту чи сервісу, що надсилає вам листи кілька тижнів, — найпростіше відкрити нову тимчасову скриньку, коли стара зникне. Кожен новий сеанс отримує свіжі 7 днів і абсолютно нову адресу. Пам’ятайте, що нова скринька матиме іншу адресу, тож акаунти чи сервіси, зареєстровані на стару, автоматично не перейдуть. Плануйте тестові сеанси відповідно.
GUID у вашому URL — що він означає після завершення строку
Ваш сеанс прив’язаний до унікального GUID (глобально унікального ідентифікатора), який зберігається у двох місцях: в URL браузера як параметр запиту та в localStorage браузера. Саме цей GUID дає змогу повертатися до тієї самої скриньки будь-коли протягом її 7 днів. Закрийте вкладку, відкрийте знову, перейдіть за URL — поки строк сеансу не сплив, ваша скринька на місці з усіма листами.
Після завершення строку GUID втрачає сенс. На сервері більше немає пов’язаного з ним запису. Якщо ви спробуєте відкрити URL, система визначить, що GUID сеансу більше не дійсний, і запропонує створити новий сеанс. Якщо ви поділитеся URL з кимось або хтось інший якось його отримає, після завершення строку там нічого не буде — ні скриньки, ні листів, ні даних сеансу. GUID — це просто випадковий рядок, що вказував на щось, чого більше не існує.
Це відповідає найкращим практикам безпеки, які рекомендує OWASP: ідентифікатори сеансів мають мати обмежений час життя й не існувати довше, ніж потрібно. Сеанс із фіксованим обмеженим часом життя, що не містить персонально ідентифікованої інформації, становить мінімальний ризик, навіть якщо URL якось потрапить до сторонніх.
А як щодо листів, що надійшли до завершення строку?
Кожен лист, що надійшов під час вашого сеансу, зберігається 7 днів із моменту надходження, а потім назавжди видаляється задачею очищення — разом із самим сеансом, коли строк скриньки сплив. Повернути їх потім неможливо. Листи нікуди не пересилаються, не потрапляють у резервні копії й не зберігаються в жодній формі. Коли зникає сеанс, зникає й усе, що з ним пов’язано.
Якщо під час сеансу ви отримали щось важливе, що треба зберегти, — номер підтвердження, облікові дані, ліцензійний ключ, посилання на завантаження документа, — збережіть цю інформацію до того, як строк скриньки спливе. Скопіюйте потрібний текст у нотатки, перешліть важливий вміст на свою справжню адресу, зробіть знімок екрана чи завантажте вкладення. Щойно скринька зникне, цей вміст не зможе відновити ніхто, зокрема й команда TempEmail.ai. Це не обмеження, яке ми могли б виправити, якби захотіли, — це базовий принцип дизайну: видалене — видалено.
Чому це добре для вашої приватності
Модель автовидалення має вагому перевагу для приватності, яка виходить за межі простого прибирання після тестового сеансу. Оскільки TempEmail.ai видаляє все автоматично, немає довгострокової бази даних про ваше користування, про яку варто хвилюватися. Немає запису про те, у яких сервісах ви реєструвалися з тимчасовими адресами. Немає історії отриманих листів. Не будується профіль на основі ваших звичок. Немає списку адрес, які можна було б пов’язати з вами. Відсутність цих даних — не недогляд, а суть продукту.
GDPR та подібні правила захисту приватності в усьому світі дають користувачам право на видалення їхніх даних. Право на видалення — його ще називають «правом бути забутим» — одне з найважливіших прав у сучасному законодавстві про захист даних. Архітектура TempEmail.ai робить це право автоматичним і універсальним: вам не треба просити про видалення, бо воно закладене в дизайн і відбувається для кожного користувача щоразу. Посібник британського ICO із захисту даних наголошує, що політика зберігання даних має бути проактивною, а не реактивною, — саме так і працює ця система.
У світі, де про витоки даних повідомляють щотижня, а компанії звично тримають дані, які їм зовсім не потрібні, сервіс, що справді видаляє ваші дані через 7 днів, — це не просто зручно. Це принципова позиція щодо того, як мають працювати онлайн-інструменти.
Практичні поради для розробників
Якщо ви використовуєте тимчасову пошту для розробки й QA-тестування, ось як ефективно працювати з 7-денним життєвим циклом:
Для коротких тестів — реєстрація, підтвердження email, скидання пароля, підтвердження акаунта — одного сеансу більш ніж досить. Відкрийте нову скриньку, запустіть надсилання листа із застосунку, отримайте його, клікніть посилання або скопіюйте код — і готово. Такі тести зазвичай займають менше п’яти хвилин. Про таймер можна взагалі не думати.
Для довших тестових сеансів — тестування серій сповіщень, таймінгу листів, багатокрокового онбордингу чи сценаріїв з очікуванням відкладених листів — 7 днів покривають майже будь-яку реалістичну послідовність, від вітального листа через 30 хвилин після реєстрації до нагадування через тиждень. Плануйте тести так, щоб вони завершувалися в цих межах, або побудуйте їх так, щоб кожна велика фаза тесту використовувала нову скриньку. Записуйте, яку тимчасову адресу ви використали для якого сценарію, щоб відстежувати результати. Якщо ваш застосунок надсилає дуже пізній лист (наприклад, лист для повернення користувача через три тижні після реєстрації), він прийде вже після завершення строку скриньки — краще скоротіть цю затримку в тестовій конфігурації.
Для автоматизованого тестування: ніколи не прописуйте тимчасову адресу жорстко в тестових скриптах. Генеруйте нову адресу для кожного прогону, створюючи новий сеанс через API. Так кожен тест стартує зі справді чистого стану — без залишкових листів із попередніх прогонів і без спільного стану між тестами. Це краща практика тестування незалежно від 7-денного ліміту, бо вона усуває поширене джерело нестабільних тестів: залишкові дані з попередніх прогонів, що забруднюють поточний. Окрема скринька тимчасової пошти для кожного прогону — добра практика, яка гарантує, що ви щоразу тестуєте зі справді чистого стану.
Поштова інфраструктура за лаштунками
Листи на вашу тимчасову адресу йдуть стандартною поштовою інфраструктурою інтернету — SMTP-сервери, пошук MX-записів у DNS, маршрутизація пошти, — і все це регулює RFC 5321, базовий протокол передавання пошти. З погляду поштового сервера відправника ваша тимчасова адреса — цілком звичайна адреса на цілком звичайному поштовому сервері. Лист доставляється звичайними каналами, його приймає інфраструктура TempEmail.ai, зберігає в базі даних і в реальному часі надсилає у ваш браузер через WebSocket. Тимчасовість скриньки абсолютно непомітна для тих, хто на неї пише, — доки строк адреси не спливе й наступні спроби доставки не почнуть повертатися.
Це означає, що листи на вашу тимчасову адресу доставляються так само надійно й швидко, як на будь-яку іншу. Немає жодної особливої маршрутизації, затримок чи фільтрації понад стандартний захист від спаму. Ви отримуєте лист так швидко, як дозволяє поштова інфраструктура інтернету, — у більшості випадків за лічені секунди.
Підсумок
Саме 7-денний життєвий цикл робить тимчасову електронну пошту справді тимчасовою — не лише на словах, а й на ділі. Це не маркетингова етикетка на системі, яка тихо зберігає ваші дані. Це жорстке технічне обмеження, закладене в архітектуру системи. Дані, що автоматично видаляються, не можуть спричинити проблем згодом — ні вам, ні комусь іншому.
Electronic Frontier Foundation давно обстоює принцип мінімізації даних — ідею, що сервіси мають збирати й зберігати лише справді потрібні дані й лише стільки, скільки потрібно. Автовидалення через 7 днів — це цей принцип, сприйнятий серйозно. Коли 7 днів минають, даних більше немає. Це не обмеження — у цьому весь сенс.