Why we don't store auth cookies¶
Mailexam is a service for testing outbound mail in development, QA, and CI/CD. In the dashboard we do not write our own authorization cookies to the browser: for information security, the session relies on a refreshable token, not a long-lived session cookie.
Yandex.Metrica is enabled on the website—its cookies (for example _ym_uid) may appear in the browser. Those belong to the analytics service, not to our sign-in mechanism.
Below: how these two cookie types differ, why we dropped auth cookies, and what we do not do with user data.
At a glance¶
| Mailexam | |
|---|---|
| Our own sign-in cookies | No — refreshable token |
| Yandex.Metrica cookies | Yes — counter on the site |
| Selling data to third parties | No |
| Retargeting and ad networks | No |
| Profiling for advertising | No |
| Purpose of the service | Only receiving and viewing test mail for your projects |
Two different kinds of cookies¶
Not all cookies are the same. A typical SaaS site may set several kinds at once:
| Type | Who sets it | Purpose | At Mailexam |
|---|---|---|---|
| Session / auth cookie | The service itself | Dashboard sign-in, “remember” the session | We do not use this |
| Analytics cookies | A counter (Yandex.Metrica, etc.) | Visit stats, traffic sources | Yes — Yandex.Metrica |
| Ad / tracking cookies | Ad networks, pixels | Retargeting, audience enrichment | No |
Confusion appears when “we don't use cookies” is read as “nothing stays in the browser”. In practice we mean our authorization model: we deliberately do not put a dashboard access token in a cookie.
Why we don't store our own auth cookies¶
The classic “session ID in a browser cookie” pattern is convenient, but for a service whose sandboxes often receive sensitive test mail, we reduce risk:
1. Less valuable cargo in the browser¶
An auth cookie is a key to the account. If it is stolen (XSS, a malicious extension, a shared device), an attacker can act as you. Skipping a long-lived session cookie shrinks the window and the method for that theft.
2. Controlled access rotation¶
A refreshable token allows short-lived access and rotation without a “forever” browser record. A compromised token lives for less time; renewal can be revoked on the server.
3. Clear separation: dashboard ≠ marketing¶
Many products blend auth cookies with analytics and ads—one identifier spans the whole stack. We do not tie sign-in to ad profiling; login only serves work in the dashboard.
4. Fit for a narrow product¶
Mailexam exists to catch test mail over SMTP. We do not need “eternal browser memory” for marketing—we need a safe session to read messages and manage projects.
How dashboard sign-in works¶
- You sign in with login and password (or another method your account supports).
- The server issues a refreshable token—not a classic Mailexam auth cookie in the browser.
- While the session is active, the dashboard and its API use that token; when needed it is refreshed according to server rules.
- Sign-out or expiry ends access without a permanent authorization cookie.
We do not use our own cookies for:
- cross-site ad analytics;
- “reminding” you about Mailexam on other domains;
- sending your ID to ad networks.
API and CI/CD
Integrations from the examples and REST API do not depend on browser cookies—only project credentials (SMTP, API keys) and test messages.
Yandex.Metrica and its cookies¶
The public pages on mailexam.io run Yandex.Metrica. It may write its own cookies to the browser and collect aggregate statistics: page views, referrers, technical visit parameters.
What matters:
- these are Yandex cookies, not our sign-in mechanism;
- we use Metrica to understand how the site is used (docs, landing), not to sell audiences;
- we do not connect Metrica to retargeting and do not build ad profiles of dashboard users;
- retention and processing for the counter follow Yandex terms.
If you never open the dashboard, Metrica may still “recognize” the browser with its identifier—that is normal counter behavior. It does not mean Mailexam stores an auth cookie for you.
Our position on data¶
We do not monetize you as a site audience:
- we do not sell or hand data to brokers and ad networks;
- we do not run retargeting based on visits to mailexam.io;
- we do not link landing-page views to ad campaigns;
- we do not build “user interests” for third parties.
The service is built for one job: mail testing in an isolated environment. Messages do not reach real recipients—they land in your Mailexam project, where you inspect them, automate checks, and use the API.
What we still process (and why)¶
| Data | Why |
|---|---|
| Account and projects | Separate SMTP logins and inboxes |
| Messages sent to your Mailexam over SMTP | That is the product—the test inbox |
| Technical logs (SMTP errors, delivery) | Reliability and support |
| Session token when signing into the dashboard | Authorization without an auth cookie in the browser |
| Aggregate site statistics (Metrica) | Improving docs and navigation |
We do not collect a dashboard activity feed for advertising and do not send message content to analytics or ad systems.
Test messages
Sandboxes often contain sensitive content: password-reset links, one-time codes, test PII. That is why we avoid expanding the authorization attack surface with extra long-lived cookies.
Compared to typical SaaS¶
| Practice | Often elsewhere | Mailexam |
|---|---|---|
| Auth cookie in the browser | Yes | No — refreshable token |
| Yandex.Metrica counter | Often + retargeting | Yes, without retargeting |
| Visit-based retargeting | Common | No |
| Audience resale | Via data partners | No |
| “Every click” dashboard analytics | Common | Not for surveillance; focus on mail |
FAQ¶
Do you have any cookies at all?
Yandex.Metrica cookies may be present. Mailexam does not set its own authorization cookies—the dashboard uses a refreshable token.
How do you stay signed in without an auth cookie?
The server issues and periodically refreshes an access token. That serves the dashboard session, not “eternal” browser recognition for marketing.
Does skipping auth cookies hurt security?
The opposite: we deliberately avoid storing an account key in a cookie to reduce risk. Account protection does not require ad tracking cookies.
Is Metrica surveillance?
Metrica gives us aggregate site statistics. We do not use it for retargeting or sell data. An auth cookie for dashboard sign-in is still not set.
What about API and CI?
Yes. The examples and API work with project credentials, without browser cookies.
Questions about privacy or data handling: support@mailexam.io.