(Чому) Пошта Mail.Ru включає суворий DMARC



Днями ми анонсували включення суворої DMARC-політики на всіх доменах, що належать Поштою Mail.Ru. На деяких доменах, включаючи bk.ru і mail.ua політика p=reject включена вже зараз. У цій статті ми хочемо пояснити деякі технічні деталі такого включення і дати рекомендації власникам сервісів, поштових серверів і списків розсилки.

Що таке DMARC?
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) — протокол, що дозволяє адміністратора доменної зони опублікувати політику прийому і відправлення звітів для листів, що не мають авторизації. В якості протоколів авторизації використовуються протоколи SPF (RFC 7208) і DKIM (RFC 6376).

Як працює DMARC?
При отриманні листа, у якого в полі відправника (From:) використовується домен example.org сервер одержувача запитує політику DMARC домену example, яка публікується в DNS у вигляді TXT, наприклад

_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:a@example.org; ruf=mailto:f@example.org; fo=1;"
 


Для письма перевіряється і DKIM SPF; крім цього, перевіряється відповідність (alignment) домену, що пройшов перевірку SPF або DKIM, і домену, який використовується під From:. Щоб домен пройшов авторизацію DMARC, необхідно, щоб хоча б один з механізмів DKIM SPF або пройшов авторизацію для домену, який співпадає з точністю до домену організації з адреси From:. Якщо лист не проходить авторизацію або домен не збігається (наприклад, використана DKIM-підпис стороннього домену або адресу в envelope-from не збігається з адресою From:), застосовується політика (в даному випадку none, тобто ніяких спеціальних дій не вимагається; можливі також політики reject — не приймати листи і quarantine — складати листа в папку «Спам»). Статистичні звіти по спрацьовуванню політики та пройшли листів будуть надсилатися на адресу a@example.org. Також домен, який публікує політику, просить надсилати форензик-звіти (тобто звіти, що містять як мінімум заголовки отриманого листа) по всім листам, які не пройшли авторизацію DKIM SPF або, на адресу f@example.org.

Що змінилося зараз?
Mail.Ru першим в Рунеті підтримав серверну частину DMARC більше двох років тому. А тепер DMARC буде захищати від підробки домени mail.ru. Раніше сувора політика DMARC була включена тільки для службових доменів Mail.Ru Group (наприклад, corp.mail.ru), оскільки саме вони найчастіше підробляються фішерами. В даний час вона також застосовується для доменів mail.ua і bk.ru, а 18 травня буде поширена на всі домени безкоштовних поштових скриньок (list.ru, inbox.ru і mail.ru).

Навіщо це Mail.Ru?
DMARC усуває саму серйозну проблему електронної пошти відсутність перевірки адреси відправника. Найчастіше причиною для введення DMARC називають боротьбу з фишинговыми листами. Частково це дійсно так — введення суворої політики DMARC всього декількома великими банками США у 2014 році привів до зниження фішингу допомогою електронної пошти на 6% за рік в цілому по галузі. В PayPal обсяг фішингу за два роки після введення політики знизився на 70%.

У разі доменів публічної пошти основною причиною є не фішинг. Ми хочемо, по-перше, в цілому знизити обсяг спаму в Мережі: більша його частина йде саме з підроблених адрес, в деякі дні кількість таких листів з підробленими адресами mail.ru більш ніж у 15 разів перевищує кількість листів, що відправляються користувачами Mail.Ru. По-друге, DMARC дозволяє захистити користувачів від вторинного спаму. Дуже часто спамние листи з підроблених адрес генерують повідомлення про неможливість доставки (NDR) і автовідповіді, які йдуть на ящики легітимних користувачів, не що надсилали листа. Розпізнати таку ситуацію може бути досить складно, так як в NDR і автоответе відсутній «спамний» контент. З нашого досвіду, впровадження суворої політики DMARC знижує обсяг вторинного спаму в кілька десятків разів.

Хіба все це не було в SPF (DKIM, Sender-ID, ADSP)?
SPF (RFC 7208) зовсім не захищає адресу відправника, так як працює тільки з адресою envelope-from, який невидимий користувачеві. DKIM (RFC 6376) теж абсолютно не захищає адресу відправника, оскільки є алгоритмом підпису і не вказує, як діяти, якщо підпису немає або вона некоректна. Sender ID (RFC 4406) прикритий патентами Microsoft і «не злетів». Найближчим по функціоналу до DMARC був протокол ADSP (RFC 5617), але, на відміну від DMARC, він також «не злетів» і в 2013 році був переведений у статус Historic, так як майже всі великі гравці ринку відмовилися від нього на користь DMARC. На відміну від ADSP, який працював тільки поверх DKIM, DMARC може використовувати різні протоколи аутентифікації. У базовому стандарті застосовуються і DKIM, і SPF. Фактично DMARC комбінує механізми, задіяні в Sender ID і ADSP, і дає можливість розширювати їх у майбутньому, що значно покращує «непряме» проходження пошти (indirect flows). Вже зараз можна не сумніватися, що протокол DMARC працює, — серверна частина DMARC підтримується всіма серйозними поштовими службами, всі великі гравці або вже включили DMARC на своїх доменах, або заявили про такий намір. Серед публічних поштових служб, які включили DMARC на своїх доменах (і прийняли основний удар критики від власників списків розсилки, про що мова піде нижче), — Yahoo і AOL. З їхнього боку це було ризикованим, але дуже потрібним рішенням — інакше протокол могла б спіткати доля Sender ID і ADSP.

У чому підступ?
Природно, у будь-якого протоколу є недоліки. DMARC вимагає аутентифікації відправника, з-за цього в декількох ситуаціях виникають проблеми:

  1. Користувач надсилає листи «безпосередньо» в обхід поштового сервера з аутентифікацією. Наприклад, веб-майстер відправляє реєстраційні листи PHP-скриптом, використовуючи під From: адреса публічної пошти. На жаль, єдине рішення — так не робити. Зареєструйте пошту для свого домена. Mail.Ru надає для цього безкоштовний сервіс. Навіть якщо ви перейдете на відправку з адреси іншої публічної пошти, швидше за все, це рішення буде тимчасовим, оскільки DMARC для своїх доменів стануть впроваджувати всі великі поштові сервіси.
  2. Списки розсилки. Так, з ними знову є проблеми, і більш істотні, ніж у випадку з SPF, так як SPF виявився марним саме із-за спроб зберегти сумісність зі списками розсилки. Щоб не порушувати авторизацію DMARC, необхідно або «не чіпати» заголовки, підписані DKIM (зокрема, не змінювати тему листа), або перезаписувати відправника з From:. На щастя, основні менеджери списків розсилки вже підтримує коректну роботу з DMARC.
  3. Форварди. У деяких випадках поштові сервери змінюють вміст при пересиланні, наприклад структуру MIME-частин або розбивку на рядки, що може призводити до порушення DKIM-підписи. У таких випадках ми рекомендуємо замість пересилання пошти використовувати збір пошти по протоколах POP3/IMAP (reverse POP / reverse IMAP). Mail.Ru перша з поштових служб реалізувала збір пошти IMAP із збереженням структури папок. Крім того, великі поштові сервіси, в тому числі Mail.Ru, підтримують білі списки відомих форвардеров (known forwarders) — для списків розсилок та інших поштових служб, пошта від яких приймається навіть у разі порушення DMARC. Якщо листи від відомого форвардера або списку розсилки блокуються нами з політики DMARC — ласка, повідомте про це. В майбутньому проблема форвардів може бути вирішена реалізацією протоколу ARC (Authenticated Received Chain), поки цей протокол знаходиться в стадії обговорення.
  4. Є й інші проблеми DMARC, в тому числі пов'язані з безпекою, особливо при наданні forensic-звітів. Наприклад, можливість розкривати перенаправлення (і таким чином деанонимизировать користувача) або передплатників списків розсилки. Все це можливо і без DMARC, але DMARC помітно полегшує завдання. Тому ми реалізували функцію анонімайзера — як альтернативу пересилок або разових/прихованих адрес для списків передплати. З міркувань безпеки ми не плануємо надавати forensic-звіти з повною ідентифікацією одержувача недоверенным сторонам.
Що мені робити, якщо...
… я звичайний користувач пошти

Нічого робити не потрібно. Скоріше за все, ви нічого не помітите, лише уникнете ситуацій «хто-то отримав спам/фішинг з моєї адреси, а я його не надсилав» і не будете отримувати незрозумілі «отлупы».

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

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

… я користуюся перенаправлениями для закладу прихованих/тимчасових адрес

Перенаправлення можуть бути виявлені і розкриті (для цього достатньо підтримки DMARC сервером одержувача, тобто практично будь-яким сервером). Якщо це критично для вас, використовуйте функцію анонімайзера.

… я користуюся функціоналом «відправляти» на Gmail (або аналогічним) для відправки листів з адреси Mail.Ru

Слід перевірити налаштування адреси відправки в Gmail і переконатися, що відправка йде через сервер SMTP mail.ru (smtp.mail.ru, порт 465 з використанням SSL), c коректним логіном і паролем. Листи будуть надсилатися через сервер Mail.Ru з авторизацією відправника і пройдуть перевірки SPF/DKIM/DMARC.

… я користуюся зворотною адресою публічної пошти для відправки листів через скрипти на сервері

Так робити не слід. Використовуйте «Пошту для бізнесу» для закладу ящиків у вашому власному домені (hint: для цього не обов'язково володіти бізнесом, достатньо володіти доменом). Використовуйте адресу власного домену у всіх серверних, автоматичних або автоматизованих розсилках.

… я надаю клієнтам послуги доставки електронних повідомлень (ESP)

Не використовуйте для заголовку From: повідомлень адреса відправника з доменів безкоштовної пошти. Зареєструйте окремий домен для клієнтів, які не мають власного домену, налаштуйте для нього SPF, DKIM і DMARC. Виділяйте клієнту адресу в домені для використання в якості адреси відправника та прописуйте перенаправлення з виділеного адреси у вашому домені на скриньку електронної пошти клієнта. Клієнтам, які мають власний домен, рекомендуйте брати адреси з цього домену в якості адреси відправника. Можна продовжувати використовувати адресу клієнта в домені безкоштовної пошти для заголовків Sender: і Reply-To:.

… я адмініструється списки розсилки

Оновіть програмне забезпечення списків розсилки і налаштуйте його у відповідності з рекомендаціями сумісності DMARC. Коректно працюють Sympa з версії 6.2.6, Dada Mail з версії 7.0.2, Mailman версія 2.1.16 (краще 2.1.18), GroupServer з версії 14.06. Можливо, доведеться включити функцію, яка називається «Sending on behalf of» / «Munge the From: header». Якщо рекомендації виконати неможливо (наприклад, використовується застаріле або непідтримувану ПО), постарайтеся мінімізувати порушення DMARC, відмовившись від зміни службових заголовків і вмісту листів, що відправляються в список розсилки, тобто не міняйте теми, не додавайте хідер/футер до листів, щоб не порушувати DKIM-сигнатуру листи. Якщо проблеми з доставкою зберігаються, зверніться в службу підтримки сервера, який не приймає повідомлення.

… я адмініструється поштовий домен і хочу опублікувати свою DMARC-політику

Налаштуйте DKIM SPF і для всіх надісланих листів, при цьому врахуйте специфіку вимог нових версій стандартів. Остання версія стандарту SPF (RFC 7208) вимагає наявності SPF-записи не тільки для основного поштового домену, але і для імен з команди HELO/EHLO, які, як правило, збігаються з канонічними іменами поштових серверів. Це необхідно для проходження SPF у разі порожнього відправника, використовуваного в NDR/MDN. Опублікуйте DMARC-запис з політикою none. Налаштуйте адреси для збору звітів rua/ruf. Зверніть увагу, що стандарт DMARC вимагає, щоб домен, в якому знаходяться дані адреси, відповідав домену, для якого запитуються звіти, або публікував спеціальну політику прийому звітів, тому отримувати звіти на адреси публічних пошт так само не вийде. Проаналізуйте надходять звіти, вирішити проблеми, пов'язані з SPF, DKIM і невідповідністю (misalign) доменів з вашої мережі, ідентифікуйте можливі джерела легальних листів за її межами (наприклад, розсилки, організовані через зовнішні сервіси розсилок) і підстройте і DKIM SPF для всіх легальних листів. Можна користуватися послугами спеціалізованих сервісів — Agari, Return Path, Dmarcian. Сервіс Dmarcian, крім платних послуг, пропонує зручний безкоштовний інструмент для візуального представлення XML-звітів DMARC. Коли всі проблеми будуть усунені, переведіть політику на reject або quarantine.

… я адмініструється поштовий сервер і хочу фільтрувати листи DMARC

Інтегруйте відповідний фільтр. Фільтрація за DMARC підтримується практично в усіх антиспам-рішеннях. В якості окремих безкоштовних DMARC-фільтрів, сумісних з основними Linux/UNIX MTA, можна порекомендувати OpenDMARC і yenma.

… я адмініструється поштовий сервер/домен і цей ваш SPF/DKIM/DMARC не знаю і знати не хочу

По мірі впровадження суворої політики DMARC іншими поштовими доменами ваш домен, не захищений політикою DMARC, буде все частіше використовуватися спамерами як джерело фальшивих адрес відправників, що приведе до постійного зростання вторинного спаму і, як наслідок, скарг користувачів. Швидше за все, в результаті ви все одно будете змушені реалізувати SPF/DKIM/DMARC. Але навіть якщо ви збережете стійкість, коли-небудь домени без опублікованій політики можуть почати сприйматися як підозрілі, в тому числі самообучающимися фільтрами, що призведе до проблем з доставляемостью листів.

… я адмініструється поштовий сервер/домен і у мене є питання

Ви можете задати їх тут у коментарях або на Тостері, я намагаюся відстежувати тематичні хаби.

висновок
Електронна пошта часто позиціонується критиками як незмінний динозавр з минулого тисячоліття — але це не так: вона розвивається, і дуже активно. Всі актуальні версії основних стандартів електронної пошти прийняті протягом останніх восьми років, DMARC став стандартом лише рік тому, а в даний час йде робота по стандартизації, наприклад, протоколів Authenticated Received Chain і SMTP Strict Transport Security. Але перехід на нові стандарти та протоколи неможливий без підтримки всіма сторонами, і ми дуже сподіваємося, що ця стаття допоможе й вам включитися в процес побудови сучасної, зручної та безпечної екосистеми електронної пошти.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.