This is the public version of the Guide. The in-app version is identical, gated behind login. If you already have an account, you'll find it under the avatar dropdown after signing in.

Guide

Everything you need to set up Mails Manager App and get the most out of your mailboxes.

Overview

Mails Manager App is a single-page dashboard for connecting multiple IMAP mailboxes and reading recent mail from one place. It was built as a portfolio project to demonstrate a small but production-shaped Django application — email-verified signup, encrypted credential storage, email-based two-factor authentication, and live IMAP access without caching message bodies on the server.

Current scope: only Mail.ru mailboxes are supported on this hosted instance.

The IMAP layer is provider-agnostic under the hood, but the documented setup and defaults in this guide are written for Mail.ru. Other providers (Gmail, Outlook, Yandex) may work with the right host and port but are not officially supported yet.

This is not a commercial service — it's a personal-use / portfolio project, open source on GitHub. Run your own copy if you want different limits or a different provider.

Getting started

Creating your portal account takes about a minute.

1
Sign up. Open the signup page on the live app and submit your email and a password. We send a verification link to that email.
2
Verify the link. Open the message titled "Confirm your Mails Manager App account" and click the link inside. If it's not in your inbox, check the Spam folder — first messages from a new sender often land there.
3
Log in. Sign in with your email and password at the login page.
4
Enter the 6-digit code. Two-factor authentication is on by default. After password login you'll be asked for a 6-digit code, also sent to your email. The code expires after a few minutes; you can request a new one from the same screen.
5
Land on your dashboard. From the home screen you can open the inbox, manage accounts, or edit your profile.

Adding your first Mail.ru account

Mail.ru is what we support today. Before you connect a mailbox, you need to let Mail.ru itself know that IMAP access is allowed for it.

On Mail.ru

1
Sign in to your Mail.ru account in a browser.
2
Open Settings → All settings → Mail clients and turn on IMAP access for the mailbox.
3
If you have two-step verification enabled on Mail.ru itself, generate an application password from the Mail.ru security settings. Mail.ru will reject your regular password from third-party clients in that case. Use the app password below — not your account password.

In Mails Manager App

1
Open the Accounts page and click Add account.
2
Fill in:
  • Email address — your Mail.ru address.
  • Password — the app password from Mail.ru, or your regular password if Mail.ru-side 2FA is off.
  • IMAP host — imap.mail.ru.
  • IMAP port — 993 (SSL).
  • Group — optional label to organise mailboxes (e.g. work, signups).
3
Save. On the accounts list, hit Test to confirm the credentials are accepted by Mail.ru. The status dot turns green on success.
The password is encrypted with Fernet before it touches the database — see Security & privacy.

Mail.ru aliases trick

One real Mail.ru registration can give you up to ten different addresses. Mail.ru calls these aliases: extra email addresses you create from inside one Mail.ru account, each of which is its own valid IMAP login. That's how you turn a single Mail.ru signup into ten connectable mailboxes in this portal.

Create the aliases on Mail.ru

1
Sign in to your Mail.ru account.
2
Open Settings → All settings → Aliases (in Russian: Настройки → Анонимайзер / Псевдонимы).
3
Click Add alias and pick a new local part. You can also choose between the @mail.ru, @inbox.ru, @list.ru and @bk.ru domains. Repeat until you have as many aliases as you want (Mail.ru caps this at around 10).
4
If Mail.ru-side 2FA is on, generate a fresh application password. The same app password works for the parent account and its aliases.

Connect them here, in bulk

Instead of adding each alias one by one, use Accounts → Bulk add and paste a small CSV. One line per alias, four columns: 

alias1@mail.ru,app-password,imap.mail.ru,993
alias2@inbox.ru,app-password,imap.mail.ru,993
alias3@list.ru,app-password,imap.mail.ru,993

Columns are email, password, IMAP host, IMAP port, in that order. Empty lines are ignored. After submitting, the portal shows which lines were added, skipped as duplicates, or blocked by the account cap.

Heads-up: each alias counts as one account against your portal cap.

Bulk add is currently a premium feature. If you're on the default tier you can still add aliases — just one at a time from the Accounts page.

Account limits

Each user on this hosted instance has a cap on how many IMAP accounts they can connect. The cap exists to keep the portfolio instance lightweight; it's not a paywall. Two ways to get a raised cap:

  • Ask the admin to raise your cap on this instance.
  • Self-host. The project is open source on GitHub — run your own copy with whatever cap you want. See Self-hosting for the setup steps.

Once you're signed in, the Limits page shows your current usage and the exact cap that applies to your account.

Two-factor authentication

Every new portal account has 2FA on by default. After your password, you enter a 6-digit one-time code that we send to your verified email address. Codes expire after a few minutes, and after several wrong attempts the code is invalidated and you'll need to request a new one.

You can toggle 2FA on or off from your Profile page. We strongly recommend keeping it on: this portal stores the IMAP passwords for every mailbox you've connected, so a stolen portal password without 2FA would expose every linked inbox.

The 6-digit code is delivered to the same email you signed up with. If you lose access to that email, password reset and login will not work — there's no out-of-band recovery channel.

Inbox & email actions

The Inbox view talks to your IMAP servers live — nothing is cached on our side. Each load fetches the latest messages straight from Mail.ru.

Filters

  • Window — 1 day, 7 days, or 30 days back.
  • Folder — Inbox, Sent, Spam, or All.
  • Account — narrow to one connected mailbox.
  • Group — narrow to mailboxes you've tagged with a group label (the optional field you set when adding an account).

Per-message actions

  • Open — read the full body of the message.
  • Mark unread — flip a read message back to unread on the server.
  • Delete — move the message to Trash on the server. This is real deletion, not a portal-only hide.

Security & privacy

This portal holds the IMAP credentials and live mail of every connected mailbox, so security is treated as a first-class concern, not an afterthought. Here's what's actually in place.

Your credentials

  • Portal password is hashed, never stored in plaintext. Django's default password hasher writes a salted PBKDF2-SHA256 digest (hundreds of thousands of iterations per password) to the database. At login we re-hash what you typed and compare against the stored digest; the original password is never written anywhere on the server.
  • Password strength is enforced at signup. Django's standard validators reject too-short passwords, all-numeric passwords, passwords too similar to your email or username, and passwords on the well-known common-password list.
  • IMAP passwords are encrypted at rest. Stored as Fernet ciphertext using a FIELD_ENCRYPTION_KEY that is separate from Django's SECRET_KEY. Passwords are never written to logs.
  • Message bodies are never persisted. The Inbox fetches them live from IMAP on every request; the server keeps no cache. Close the tab and the messages stay only on your Mail.ru side.

Hardening on every request

  • HTTPS everywhere in production. SECURE_SSL_REDIRECT forces HTTPS, and HSTS is preloaded with includeSubDomains so browsers refuse to fall back to plain HTTP.
  • Secure, HttpOnly, SameSite=Lax cookies. Session and CSRF cookies can't be read by JavaScript or sent on cross-site requests in normal flows.
  • No clickjacking. X-Frame-Options: DENY blocks every attempt to embed the portal in a frame, on every page.
  • No MIME sniffing, minimal referrer leakage. X-Content-Type-Options: nosniff and Referrer-Policy: same-origin are set explicitly.
  • No HTML caching. A custom no-cache middleware tags every HTML response so logged-in pages don't sit in proxy or browser caches after you log out.
  • Rate limiting on auth endpoints. Login, signup, OTP entry, OTP resend, and password reset all have per-user / per-IP budgets backed by Django's cache; abusive bursts get blocked.

For more depth, see the dedicated Security page.

Need something this guide doesn't cover? Open an issue on GitHub.