AliasX

Що захищає вхідний поштовий аліас і де його межі

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

Вхідний аліас дозволяє дати сервісу адресу, відмінну від основної пошти. Для кожної реєстрації можна використовувати окрему адресу й отримувати на неї повідомлення. Це корисна межа приватності: одним потоком листів можна керувати незалежно від решти облікових записів.

Щоб користуватися нею усвідомлено, розділіть чотири запитання: чи можна відповісти, як відновити доступ, які відомості розкриває пошта й що саме захищає шифрування? Аліас розв'язує лише частину кожного завдання.

Приймання листів і відповіді — різні можливості

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

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

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

Також відрізняйте відповідь від переходу за посиланням. Персональне посилання може містити відомості, пов'язані з отримувачем. Доставка на аліас не робить усі наступні дії анонімними. Окремо перевіряйте адресу призначення та зміст дії.

Відновлення створює залежність

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

Перед вимкненням перегляньте всі облікові записи, які використовують адресу. За потреби замініть e-mail відновлення, завершіть підтвердження та перевірте дані входу. Якщо доступні незалежні способи відновлення, розберіться в них і підтримуйте їхню придатність.

Є і друга залежність — доступ до самого AliasX. Матеріали відновлення свого облікового запису зберігайте безпечно й так, щоб вони були доступні після втрати початкового браузера. Не вважайте, що повернення можливості ввійти завжди означає можливість розшифрувати стару пошту без необхідних матеріалів.

Не будуйте єдиний шлях відновлення через адресу, яку можна відкрити лише після входу в той самий обліковий запис. Якщо ланцюжок важко пояснити, намалюйте його: чим зможете скористатися після втрати поточного пристрою?

Адреса — лише частина метаданих

Лист містить не тільки основний текст. Стандартні заголовки включають поля відправника й отримувача, дату, ідентифікатори повідомлення та відомості про проходження. Вони потрібні для доставки й організації розмов. Заміна адреси призначення не прибирає решти формату. Формат інтернет-листів, RFC 5322.

Сайт також знає те, що ви повідомляєте безпосередньо. Покупка може бути пов'язана з адресою доставки, оплатою та історією облікового запису. Різні аліаси не роблять ці записи незалежними. Однакове ім'я або інші ідентифікаційні відомості можуть пов'язувати їх без e-mail.

Окрема межа — зовнішній вміст листа. Завантаження із сервера відправника може розкривати відомості про активність або мережу. Поштові програми можуть мати власні налаштування захисту. Наприклад, Apple Mail описує керування видимістю IP і зовнішнім вмістом. Це інші механізми, ніж зміна адреси; їх згадування не означає наявності функцій Apple в AliasX. Налаштування приватності Apple Mail.

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

Шифрування зберігання й наскрізне шифрування різняться

AliasX зберігає власний архів аліасів зашифрованим. Звичайний вхідний інтернет-лист від цього не стає повідомленням, яке відправник зашифрував для вас наскрізно. У відправника та його поштового провайдера можуть залишатися свої копії; у доставці беруть участь системи за межами вашого облікового запису.

Транспортне шифрування SMTP — ще один окремий рівень. STARTTLS захищає з'єднання між учасниками SMTP-доставки. Шифрування одного з'єднання саме собою не забезпечує конфіденційності всього шляху. SMTP поверх TLS, RFC 3207.

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

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

Джерела

  1. https://www.rfc-editor.org/rfc/rfc5322
  2. https://support.apple.com/en-ie/guide/mail/mlhlae4a4fe6/mac/1000
  3. https://www.rfc-editor.org/rfc/rfc3207