Квантово стійка електронна пошта: Як ми використовуємо зашифровані поштові скриньки SQLite для захисту вашої електронної пошти

Передмова

До запуску Підтримка IMAP ми використовували MongoDB для наших потреб постійного зберігання даних.

Ця технологія чудова, і ми досі використовуємо її, але для того, щоб мати шифрування в стані спокою з MongoDB, вам потрібно скористатися послугами постачальника, який пропонує MongoDB Enterprise, такого як Digital Ocean або Mongo Atlas, або заплатити за корпоративну ліцензію (і згодом працювати із затримкою відділу продажів).

Нашій команді в Переслати електронний лист потрібне було зручне для розробників, масштабоване, надійне та зашифроване рішення для зберігання поштових скриньок IMAP. Як розробники з відкритим кодом, використання технології, за яку потрібно сплатити ліцензійний збір, щоб отримати функцію шифрування в стані спокою, суперечило б наші принципи – тому ми експериментували, досліджували та розробляли нове рішення з нуля, щоб задовольнити ці потреби.

Замість використання спільної бази даних для зберігання ваших поштових скриньок, ми окремо зберігаємо та шифруємо ваші поштові скриньки за допомогою вашого пароля (який є лише у вас). Наш сервіс електронної пошти настільки безпечний, що якщо ви забудете свій пароль, то втратите свою поштову скриньку (і вам потрібно буде відновлювати її за допомогою офлайн-резервних копій або починати все спочатку).

Продовжуйте читати, оскільки нижче ми детально розглянемо порівняння постачальників послуг електронної пошти, як працює наш сервіс, наш технологічний стек та інші.

Порівняння постачальників послуг електронної пошти

Ми є єдиним постачальником послуг електронної пошти зі 100% відкритим кодом та орієнтованим на конфіденційність, який зберігає індивідуально зашифровані поштові скриньки SQLite, пропонує необмежену кількість доменів, псевдонімів та користувачів, а також підтримує вихідні протоколи SMTP, IMAP та POP3:

На відміну від інших постачальників послуг електронної пошти, вам не потрібно платити за сховище для кожного домену чи псевдоніма з Forward Email. Сховище розподіляється між усім вашим обліковим записом, тому, якщо у вас є кілька користувацьких доменних імен і кілька псевдонімів для кожного, то ми — ідеальне рішення для вас. Зверніть увагу, що ви все ще можете встановити обмеження сховища за потреби для кожного домену чи псевдоніма.

Читати порівняння сервісів електронної пошти

Як це працює

1. Використовуючи свій поштовий клієнт, такий як Apple Mail, Thunderbird, Gmail або Outlook, ви підключаєтеся до наших захищених серверів IMAP, використовуючи своє ім’я користувача та пароль:

• Ваше ім’я користувача – це ваш повний псевдонім у вашому домені, наприклад, hello@example.com.
• Ваш пароль генерується випадковим чином і відображається вам лише протягом 30 секунд, коли ви натискаєте Згенерувати пароль з Мій обліковий запис Домени Псевдоніми.

2. Після підключення ваш поштовий клієнт надішле Команди протоколу IMAP на наш IMAP-сервер для синхронізації вашої поштової скриньки. Це включає написання та зберігання чернеток електронних листів та інші дії, які ви можете виконувати (наприклад, позначку електронного листа як важливого або позначку листа як спаму/небажаної пошти).

3. Сервери обміну поштою (широко відомі як сервери "MX") отримують нову вхідну електронну пошту та зберігають її у вашій поштовій скриньці. Коли це трапляється, ваш поштовий клієнт отримує сповіщення та синхронізує вашу поштову скриньку. Наші сервери обміну поштою можуть пересилати вашу електронну пошту одному або кільком одержувачам (включно з вебхуки), зберігати вашу електронну пошту для вас у вашому зашифрованому сховищі IMAP у нас або і те, й інше!

4. За лаштунками наша система безпечного зберігання електронної пошти працює двома способами, щоб ваші поштові скриньки були зашифровані та доступні лише вам:

• Коли від відправника надходить новий лист, наші сервери обміну поштою надсилають його на окрему тимчасову зашифровану поштову скриньку.

  

• Коли ви підключаєтеся до нашого IMAP-сервера за допомогою поштового клієнта, ваш пароль шифрується в пам’яті та використовується для читання та запису до вашої поштової скриньки. Читання та запис даних з вашої поштової скриньки можливі лише за допомогою цього пароля. Пам’ятайте, що оскільки ви єдиний, хто має цей пароль, лише ви можете читати та записувати дані до своєї поштової скриньки, коли ви отримуєте до неї доступ. Наступного разу, коли ваш поштовий клієнт спробує запитувати пошту або синхронізувати її, ваші нові повідомлення будуть перенесені з цієї тимчасової поштової скриньки та збережені у вашому фактичному файлі поштової скриньки за допомогою наданого вами пароля. Зверніть увагу, що ця тимчасова поштова скринька згодом очищується та видаляється, тож повідомлення зберігаються лише у вашій поштовій скриньці, захищеній паролем.

• Якщо ви підключені до IMAP (наприклад, за допомогою поштового клієнта, такого як Apple Mail або Thunderbird), нам не потрібно записувати дані на тимчасове сховище на диску. Натомість отримується та використовується ваш зашифрований пароль IMAP, що зберігається в оперативній пам’яті. У режимі реального часу, коли повідомлення намагається бути доставлене вам, ми надсилаємо запит WebSocket усім серверам IMAP, запитуючи їх, чи є у них активний сеанс для вас (це частина отримання), а потім передаємо цей зашифрований пароль, що зберігається в оперативній пам’яті – тому нам не потрібно записувати дані на тимчасову поштову скриньку, ми можемо записати дані на вашу фактичну зашифровану поштову скриньку, використовуючи ваш зашифрований пароль.

  

5. Резервні копії ваших зашифрованих поштових скриньок створюються щодня. Ви також можете будь-коли запросити нову резервну копію або завантажити останню резервну копію з розділу Мій обліковий запис Домени Псевдоніми. Якщо ви вирішите перейти на інший сервіс електронної пошти, ви можете легко перенести, завантажити, експортувати та очистити свої поштові скриньки та резервні копії будь-коли.

Технології

Бази даних

Ми дослідили інші можливі рівні зберігання бази даних, проте жоден з них не задовольнив наші вимоги так добре, як SQLite:

База даних	Шифрування в стані спокою	Поштові скриньки Sandboxed	Ліцензія	Used Everywhere
SQLite :зірка:	✅ Так, з SQLite3MultipleCiphers	✅	✅ Суспільне надбання	✅
MongoDB	❌ "Available in MongoDB Enterprise only"	❌ Реляційна база даних	❌ AGPL та SSPL-1.0	:х:
rqlite	❌ Network only	❌ Реляційна база даних	✅ MIT	:х:
dqlite	❌ Untested and not yet supported?	❌ Untested and not yet supported?	✅ LGPL-3.0-only	:х:
PostgreSQL	✅ Yes	❌ Реляційна база даних	✅ PostgreSQL (подібно до BSD або MIT)	:х:
MariaDB	✅ For InnoDB only	❌ Реляційна база даних	✅ GPLv2 та BUSL-1.1	:х:
CockroachDB	❌ Enterprise-only feature	❌ Реляційна база даних	❌ BUSL-1.1 та інші	:х:

Ось допис у блозі, який порівнює кілька варіантів зберігання бази даних SQLite у таблиці вище.

Безпека

Ми завжди використовуємо шифрування-в-резервному-пакеті (AES-256), шифрування під час передачі (TLS), DNS через HTTPS ("DoH") з використанням шифрування 🍊 Мандарин та sqleet (ЧаЧа20-Полі1305) для поштових скриньок. Крім того, ми використовуємо двофакторну автентифікацію на основі токенів (на відміну від SMS, яка підозріла на атаки типу «людина посередині»), ротовані SSH-ключі з вимкненим root-доступом, ексклюзивний доступ до серверів через обмежені IP-адреси тощо.

У разі напад злої покоївки або недобросовісного співробітника від стороннього постачальника, вашу поштову скриньку все одно можна буде відкрити лише за допомогою згенерованого вами пароля. Будьте певні, ми не покладаємося на жодних сторонніх постачальників, окрім наших постачальників серверів скарг SOC Type 2, таких як Cloudflare, DataPacket, Digital Ocean та Vultr.

Наша мета — мати якомога менше єдина точка відмови.

Поштові скриньки

tldr; Наші IMAP-сервери використовують окремо зашифровані бази даних SQLite для кожної з ваших поштових скриньок.

Вбудована база даних SQLite надзвичайно популярний – вона зараз працює на вашому телефоні та комп’ютері – і використовується майже всіма основними технологіями.

Наприклад, на наших зашифрованих серверах є поштова скринька бази даних SQLite для linux@example.com, info@example.com, hello@example.com тощо – по одній для кожного як файл бази даних .sqlite. Ми також не іменуємо файли бази даних за допомогою адреси електронної пошти – натомість ми використовуємо BSON ObjectID та унікальні згенеровані UUID, які не розкривають, кому належить поштова скринька або яку адресу електронної пошти вона має (наприклад, 353a03f21e534321f5d6e267.sqlite).

Кожна з цих баз даних шифрується за допомогою вашого пароля (який є лише у вас) з використанням sqleet (ЧаЧа20-Полі1305). Це означає, що ваші поштові скриньки зашифровані окремо, автономні, пісочниця та портативні.

Ми доопрацювали SQLite, додавши наступний PRAGMA:

PRAGMA	Мета
cipher=chacha20	ChaCha20-Poly1305 SQLite database encryption. Див. better-sqlite3-multiple-ciphers у розділі Projects для отримання додаткової інформації.
key="****************"	Це ваш розшифрований пароль, що зберігається лише в пам'яті, який передається через IMAP-з'єднання вашого поштового клієнта до нашого сервера. Нові екземпляри бази даних створюються та закриваються для кожного сеансу читання та запису (для забезпечення ізольованого середовища та ізоляції).
journal_model=WAL	Журнал попереднього запису ("WAL") which boosts performance and allows concurrent read access.
busy_timeout=5000	Запобігає помилкам блокування запису while other writes are taking place.
synchronous=NORMAL	Збільшує довговічність транзакцій without data corruption risk.
foreign_keys=ON	Забезпечує застосування посилань на зовнішні ключі (наприклад, зв'язок з однієї таблиці до іншої). By default this is not turned on in SQLite, але для перевірки та цілісності даних його слід увімкнути.
encoding='UTF-8'	Default encoding для використання з метою забезпечення безпеки розробників.

Усі інші значення за замовчуванням взяті з SQLite, як зазначено у офіційна документація PRAGMA.

Паралелізм

tldr; Ми використовуємо WebSocket для одночасного читання та запису до ваших зашифрованих поштових скриньок SQLite.

Читає

Ваш поштовий клієнт на вашому телефоні може розпізнати imap.forwardemail.net як одну з наших IP-адрес Digital Ocean, а ваш клієнт для робочого столу може розпізнати окрему IP-адресу з іншої постачальник.

Незалежно від того, до якого IMAP-сервера підключається ваш поштовий клієнт, ми хочемо, щоб з’єднання зчитувало дані з вашої бази даних у режимі реального часу зі 100% точністю. Це робиться за допомогою WebSockets.

Записує

Запис у базу даних дещо відрізняється, оскільки SQLite — це вбудована база даних, а ваша поштова скринька за замовчуванням зберігається в одному файлі.

Ми розглянули такі варіанти, як litestream, rqlite та dqlite, проте жоден з них не задовольнив наші вимоги.

Щоб виконувати запис з увімкненим логуванням попереднього запису ("WAL"), нам потрібно переконатися, що за це відповідає лише один сервер ("Основний"). WAL значно пришвидшує паралельність і дозволяє одному записувачу та кільком читачам.

Основний сервер працює на серверах даних із підключеними томами, що містять зашифровані поштові скриньки. З точки зору розподілу, ви можете вважати всі окремі сервери IMAP за imap.forwardemail.net вторинними серверами ("Додаткові").

Ми здійснюємо двосторонній зв'язок з Вебсокети:

• Первинні сервери використовують екземпляр сервера WebSocketServer класу WS.
• Вторинні сервери використовують екземпляр клієнта WebSocket класу WS, який обгорнутий websocket-як-обіцяно та повторне підключення вебсокета. Ці дві обгортки забезпечують повторне підключення WebSocket та можливість надсилати й отримувати дані для певних записів у базу даних.

Резервні копії

tldr; Резервні копії ваших зашифрованих поштових скриньок створюються щодня. Ви також можете миттєво запросити нову резервну копію або завантажити останню резервну копію будь-коли з розділу Мій обліковий запис Домени Псевдоніми.

Для резервного копіювання ми просто щодня запускаємо команду SQLite VACUUM INTO під час обробки команди IMAP, яка використовує ваш зашифрований пароль з IMAP-з’єднання в пам’яті. Резервні копії зберігаються, якщо не виявлено жодної існуючої резервної копії або якщо хеш SHA-256 у файлі змінився порівняно з останньою резервною копією.

Зверніть увагу, що ми використовуємо команду VACUUM INTO, а не вбудовану команду backup, оскільки якщо сторінку змінено під час виконання команди backup, то її потрібно почати спочатку. Команда VACUUM INTO зробить знімок. Дивіться ці коментарі щодо GitHub та Новини хакерів для отримання додаткової інформації.

Крім того, ми використовуємо VACUUM INTO на відміну від backup, оскільки команда backup залишить базу даних незашифрованою на короткий період, доки не буде викликано rekey (див. цей GitHub коментар для отримання додаткової інформації).

Вторинний сервер через з’єднання WebSocket накаже первинному серверу виконати резервне копіювання, після чого первинний сервер отримає команду на це та згодом виконає такі дії:

1. Підключіться до вашої зашифрованої поштової скриньки.
2. Отримайте блокування запису.
3. Запустіть контрольну точку WAL через wal_checkpoint(PASSIVE).
4. Виконайте команду SQLite VACUUM INTO.
5. Переконайтеся, що скопійований файл можна відкрити із зашифрованим паролем (захист/фіктивний захист).
6. Завантажте його до Cloudflare R2 для зберігання (або до вашого власного провайдера, якщо вказано).

Пам’ятайте, що ваші поштові скриньки зашифровані – і хоча ми маємо обмеження IP-адрес та інші заходи автентифікації для зв’язку WebSocket – у разі зловмисника ви можете бути впевнені, що якщо корисне навантаження WebSocket не матиме вашого пароля IMAP, воно не зможе відкрити вашу базу даних.

Наразі для кожної поштової скриньки зберігається лише одна резервна копія, але в майбутньому ми можемо запропонувати відновлення на певний момент часу ("PITR").

Пошук

Наші IMAP-сервери підтримують команду SEARCH зі складними запитами, регулярними виразами тощо.

Швидкий пошук забезпечується завдяки FTS5 та sqlite-регулярний вираз.

Ми зберігаємо значення Date у поштових скриньках SQLite як рядки ISO 8601 через Date.prototype.toISOString (з часовим поясом UTC для правильної роботи порівнянь рівності).

Індекси також зберігаються для всіх властивостей, що містяться в пошукових запитах.

Проєкти

Ось таблиця, в якій перелічено проекти, які ми використовуємо у нашому вихідному коді та процесі розробки (відсортовано в алфавітному порядку):

Демонструвати	Мета
Ansible	Платформа автоматизації DevOps для легкого обслуговування, масштабування та управління всім нашим парком серверів.
Bree	Планувальник завдань для Node.js та JavaScript з підтримкою cron, dates, ms, later та зручною для користувача підтримкою.
Cabin	Зручна для розробників бібліотека логування JavaScript та Node.js з урахуванням безпеки та конфіденційності.
Lad	Фреймворк Node.js, який забезпечує всю нашу архітектуру та інженерний дизайн за допомогою MVC та інших інструментів.
MongoDB	NoSQL-рішення для баз даних, яке ми використовуємо для зберігання всіх інших даних поза поштовими скриньками (наприклад, вашого облікового запису, налаштувань, доменів та конфігурацій псевдонімів).
Mongoose	Моделювання об'єктних документів MongoDB ("ODM"), яке ми використовуємо по всьому нашому стеку. Ми написали спеціальні помічники, які дозволяють нам просто продовжувати використовувати Mongoose з SQLite 🎉
Node.js	Node.js — це кросплатформне середовище виконання JavaScript з відкритим кодом, яке запускає всі наші серверні процеси.
Nodemailer	Пакет Node.js для надсилання електронних листів, створення зв'язків тощо. Ми є офіційним спонсором цього проєкту.
Redis	База даних в оперативній пам'яті для кешування, каналів публікації/підписки та запитів DNS через HTTPS.
SQLite3MultipleCiphers	Розширення шифрування для SQLite, що дозволяє шифрувати всі файли бази даних (включно з журналом попередньої запису ("WAL"), журналом відкату тощо).
SQLiteStudio	Візуальний редактор SQLite (який ви також можете використовувати) для тестування, завантаження та перегляду поштових скриньок розробників.
SQLite	Вбудований рівень бази даних для масштабованого, автономного, швидкого та стійкого сховища IMAP.
Spam Scanner	Інструмент Node.js для захисту від спаму, фільтрації електронної пошти та запобігання фішингу (наша альтернатива Spam Assassin та rspamd).
Tangerine	Запити DNS через HTTPS за допомогою Node.js та кешування за допомогою Redis – що забезпечує глобальну узгодженість та багато іншого.
Thunderbird	Наша команда розробників використовує це (і також рекомендує це) як бажаний поштовий клієнт для використання з Forward Email.
UTM	Наша команда розробників використовує ці віртуальні машини для iOS та macOS, щоб паралельно тестувати різні поштові клієнти з нашими серверами IMAP та SMTP.
Ubuntu	Сучасна серверна операційна система з відкритим кодом на базі Linux, яка забезпечує роботу всієї нашої інфраструктури.
WildDuck	Бібліотека сервера IMAP – див. примітки до attachment de-duplication та IMAP protocol support.
better-sqlite3-multiple-ciphers	Швидка та проста API-бібліотека для Node.js для програмної взаємодії з SQLite3.
email-templates	Зручний для розробників фреймворк електронної пошти для створення, попереднього перегляду та надсилання користувацьких електронних листів (наприклад, сповіщень облікового запису тощо).
json-sql-enhanced	Конструктор SQL-запитів з використанням синтаксису в стилі Mongo. Це економить час нашої команди розробників, оскільки ми можемо продовжувати писати в стилі Mongo для всього стеку з агностичним підходом до бази даних. Це також допомагає уникнути атак SQL-ін'єкцій, використовуючи параметри запиту.
knex-schema-inspector	Утиліта SQL для вилучення інформації про існуючу схему бази даних. Це дозволяє нам легко перевірити, чи всі індекси, таблиці, стовпці, обмеження тощо є дійсними та відповідають 1:1 вимогам. Ми навіть написали автоматичні помічники для додавання нових стовпців та індексів, якщо до схем бази даних внесено зміни (з надзвичайно детальним сповіщенням про помилки).
knex	Конструктор SQL-запитів, який ми використовуємо лише для міграції бази даних та перевірки схеми через knex-schema-inspector.
mandarin	Автоматичний переклад фрази i18n з підтримкою Markdown за допомогою Google Cloud Translation API.
mx-connect	Пакет Node.js для встановлення та вирішення з'єднань із MX-серверами, а також обробки помилок.
pm2	Менеджер виробничих процесів Node.js із вбудованим балансувальником навантаження (fine-tuned для підвищення продуктивності).
smtp-server	Бібліотека SMTP-сервера – ми використовуємо її для нашого обміну поштою ("MX") та вихідних SMTP-серверів.
ImapTest	Корисний інструмент для тестування IMAP-серверів на відповідність бенчмаркам та сумісності протоколу IMAP зі специфікацією RFC. Цей проект був створений командою Dovecot (активний сервер IMAP та POP3 з відкритим кодом з липня 2002 року). Ми ретельно протестували наш IMAP-сервер за допомогою цього інструменту.

Ви можете знайти інші проекти, які ми використовуємо, у наш вихідний код на GitHub.

Постачальники

Постачальник	Мета
Cloudflare	Постачальник DNS, перевірки справності, балансувальники навантаження та сховище резервних копій за допомогою Cloudflare R2.
Digital Ocean	Хостинг на виділеному сервері та керовані бази даних.
Vultr	Хостинг виділеного сервера.
DataPacket	Хостинг виділеного сервера.

Думки

Принципи

Пересилання електронної пошти розроблено відповідно до таких принципів:

1. Завжди будьте зручними для розробників, орієнтованими на безпеку та конфіденційність, а також прозорими.
2. Дотримуйтесь MVC, Юнікс, KISS, DRY, YAGNI, Дванадцять факторів, Бритва Оккама та внутрішнього тестування
3. Орієнтуйтеся на недбалих, завантажених розробників та рамен-вигідний розробників

Експерименти

tldr; Зрештою, використання S3-сумісного об'єктного сховища та/або віртуальних таблиць технічно неможливе з міркувань продуктивності та схильне до помилок через обмеження пам'яті.

Ми провели кілька експериментів, що призвели до нашого остаточного рішення SQLite, як обговорювалося вище.

Одним із них було спробувати використати rclone та SQLite разом із S3-сумісним шаром сховища.

Цей експеримент допоміг нам краще зрозуміти та виявити граничні випадки, пов'язані з використанням rclone, SQLite та VFS:

• Якщо ви ввімкнете прапорець --vfs-cache-mode writes за допомогою rclone, то читання буде дозволено, проте запис буде кешуватися.
• Якщо у вас є кілька серверів IMAP, розподілених по всьому світу, то кеш на них буде вимкнено, якщо у вас немає одного записувача та кількох слухачів (наприклад, підхід pub/sub).
• Це неймовірно складно, і додавання будь-якої додаткової складності, подібної до цієї, призведе до появи більшої кількості точок відмови.
• Постачальники сховищ, сумісні з S3, не підтримують часткові зміни файлів, що означає, що будь-яка зміна файлу .sqlite призведе до повної зміни та повторного завантаження бази даних.
• Існують інші рішення, такі як rsync, але вони не зосереджені на підтримці журналу попереднього запису ("WAL"), тому ми зрештою переглянули Litestream. На щастя, наше використання шифрування вже шифрує файли WAL для нас, тому нам не потрібно покладатися на Litestream для цього. Однак ми ще не були впевнені в Litestream для використання у виробничому середовищі, і нижче є кілька приміток з цього приводу.
• Використання цього параметра --vfs-cache-mode writes (єдиний спосіб використання SQLite замість rclone для запису) призведе до спроби скопіювати всю базу даних з нуля в пам'ять – обробка однієї поштової скриньки розміром 10 ГБ є прийнятною, проте обробка кількох поштових скриньок з надзвичайно великим обсягом сховища призведе до того, що сервери IMAP зіткнуться з обмеженнями пам'яті та помилками ENOMEM, помилками сегментації та пошкодженням даних.
• Якщо ви спробуєте використовувати SQLite Віртуальні столи (наприклад, використовуючи s3db), щоб дані зберігалися на рівні сховища, сумісному з S3, ви зіткнетеся з кількома іншими проблемами:
• Читання та запис будуть надзвичайно повільними, оскільки кінцеві точки API S3 потрібно буде обробляти за допомогою методів HTTP .sqlite0, .sqlite1, .sqlite2 та .sqlite3.
• Тести розробки показали, що перевищення 500 тис. – 1 млн.+ записів в оптоволоконному інтернеті все ще обмежене пропускною здатністю запису та читання для S3-сумісних провайдерів. Наприклад, наші розробники виконували цикли .sqlite4 для виконання як послідовних SQL-інструкцій .sqlite5, так і для виконання великих обсягів даних. В обох випадках продуктивність була вражаюче низькою.
• Віртуальні таблиці не можуть мати індекси, інструкції .sqlite6 та .sqlite7 .sqlite8, що призводить до затримок до 1-2 хвилин або більше залежно від обсягу даних.
• Об'єкти зберігалися в незашифрованому вигляді, і вбудована підтримка шифрування відсутня. * Ми також досліджували використання .sqlite9, який концептуально та технічно схожий на попередній пункт (тому має ті ж проблеми). Можливим варіантом було б використання власної збірки rsync0, обгорнутої шифруванням, наприклад, rsync1 (яку ми зараз використовуємо в нашому рішенні вище) через rsync2.
• Іншим можливим підходом було б використання rsync3, проте це має обмеження 32 ГБ і вимагатиме складних проблем зі збіркою та розробкою.
• Необхідні оператори rsync4 (тому це повністю виключає використання віртуальних таблиць). Нам потрібні оператори rsync5, щоб наш перехоплювач з rsync6 працював належним чином, що гарантує, що дані не будуть пошкоджені, а отримані рядки можна буде перетворити на дійсні документи відповідно до наших визначень схеми rsync7 (яка включає обмеження, тип змінної та перевірку довільних даних).
• Майже всі S3-сумісні проекти, пов'язані з SQLite у спільноті відкритого коду, написані на Python (а не на JavaScript, який ми використовуємо для 100% нашого стеку).
• Бібліотеки стиснення, такі як rsync8 (див. rsync9), виглядають багатообіцяючими, але __PROTECTED_LINK_189__0. Натомість, стиснення на стороні програми для типів даних, таких як __PROTECTED_LINK_189__1, __PROTECTED_LINK_189__2, __PROTECTED_LINK_189__3, __PROTECTED_LINK_189__4, __PROTECTED_LINK_189__5 та __PROTECTED_LINK_189__6, буде чистішим та простішим підходом (і його також легше перенести, оскільки ми можемо зберігати прапорець або стовпець __PROTECTED_LINK_189__7 – або навіть використовувати __PROTECTED_LINK_189__8 __PROTECTED_LINK_189__9 для стиснення або __PROTECTED_LINK_190__0 для відсутності стиснення як метадані бази даних).
• На щастя, у нас вже реалізовано дедуплікацію вкладень у сховищі нашого IMAP-сервера – тому кожне повідомлення з однаковим вкладенням не зберігатиме копію вкладення – натомість зберігається одне вкладення для кількох повідомлень і потоків у поштовій скриньці (і згодом використовується зовнішнє посилання).
• Проект Litestream, який є рішенням для реплікації та резервного копіювання SQLite, є дуже перспективним, і ми, найімовірніше, використовуватимемо його в майбутньому.
• Не хочу дискредитувати автора(ів) – адже ми любимо їхню роботу та внесок у розробку програмного забезпечення з відкритим кодом вже понад десять років – проте з реального використання здається, що існують __PROTECTED_LINK_190__1 та __PROTECTED_LINK_190__2.
• Відновлення резервної копії має бути безперебійним та простим. Використання такого рішення, як MongoDB з __PROTECTED_LINK_190__3 та __PROTECTED_LINK_190__4, не тільки нудне, але й трудомістке та має складність налаштування.
• Бази даних SQLite спрощують це (це один файл).
• Ми хотіли розробити рішення, де користувачі могли б взяти свою поштову скриньку та піти в будь-який момент.
• Прості команди Node.js для __PROTECTED_LINK_190__5, і вона назавжди видаляється з дискового сховища.
• Ми можемо аналогічно використовувати S3-сумісний API з HTTP __PROTECTED_LINK_190__6 для легкого видалення знімків та резервних копій для користувачів.
• SQLite був найпростішим, найшвидшим та найекономічнішим рішенням.

Відсутність альтернатив

Наскільки нам відомо, жодні інші поштові служби не розроблені таким чином і не мають відкритого коду.

Ми вважаємо, що це може бути пов'язано з тим, що існуючі поштові служби використовують застарілі технології у виробництві з код спагетті 🍝.

Більшість, якщо не всі, існуючі постачальники послуг електронної пошти мають або закритий вихідний код, або рекламуються як такі, що мають відкритий вихідний код, але насправді лише їхній інтерфейс є відкритим.

Найчутливіша частина електронної пошти (фактичне зберігання/взаємодія IMAP/SMTP) виконується на сервері (бекенді), а не на інтерфейсі (клієнті).

Спробуйте пересилання електронної пошти

Зареєструйтесь сьогодні на https://forwardemail.net! 🚀