SPF - я повинен реалізовувати?

Веб-розробник зробив запит щодо записів DNS нашого домену, щоб вони включали SPF-записи TXT. Я знайшов різні думки щодо цього там ...

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

Так. Я б не назвав це суб'єктивним, оскільки існує чіткий консенсус; використовувати SPF .

Реалізація дуже проста, і це добре для Інтернету в цілому.

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

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

Я вважаю записи SPF для сервера електронної пошти більш корисними та надійними у блокуванні спаму, ніж записи електронної адреси відправника.

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

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

Я вважаю, проникнення SPF на сторону прийому, ймовірно, більше, ніж на стороні видавництва.

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

Однозначно налаштовуйте SPF - не повинно бути ніяких недоліків (якщо він налаштований належним чином і протестовано), але це не дозволить іншим сайтам маскуватися під вас і надсилати спам на ваше ім’я. Причина, чому це добре, полягає в тому, що ви явно перебуваєте в списках певних серверів / IP-адрес, які можуть надсилати електронну пошту для вашого домену.

Я вважаю, що найкращим доказом того, що це добре, є перегляд кількох основних служб електронної пошти. Просто шукайте заголовки "Отримано-SPF" в ​​оригіналі електронної пошти, щоб побачити, чи встановлено прапорці SPF. Наприклад:

Yahoo Mail:

Received-SPF: pass (domain of example.com designates xxx.xxx.xxx.xxx as permitted sender)

Gmail:

Received-SPF: pass (google.com: domain of user@example.com designates xxx.xx.xx.xx as permitted sender) client-ip=xxx.xx.xx.xx;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of user@example.com designates xxx.xx.xx.xx as permitted sender) smtp.mail=user@example.com

Hotmail також перевіряє SPF (хоча, я вважаю, вони називають це Sender-ID). Загалом, це просте доповнення, яке може принести багато корисного - як для вашого домену, так і для Інтернету в цілому.

Як і інші респонденти (поки що), я рекомендую впроваджувати SPF.

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

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

Мені, безумовно, було б дуже цікаво почути, які недоліки у SPF. Наразі все, що мені відомо:

1. користувачі повинні направляти свою вихідну пошту через номіновані сервери - хоча управління вашою вихідною поштою має очевидні переваги, це може спричинити певні ускладнення, якщо у вас віддалені користувачі - вам потрібно буде встановити автентифікацію SMTP або VPN

2. проблема з деяким переадресацією - що IME дуже рідко

Велика проблема, яку я бачу з SPF, полягає в тому, що це переправлення перерв. На сьогодні це лише коротко згадується у вікіпедії SPF . І це також причина, коли я не встановлюю SPF на своєму поштовому сервері.

Розглянемо, що A з адресою a@a.org(хто MX реалізує SPF) надсилає повідомлення на адресу B з адресою, b@b.orgяка налаштовує цю адресу, щоб пересилати повідомлення на адресу b@reallyb.org. Потім MX reallyb.orgбачить пошту A, що походить від b.orgMX MX, і тому дозволено викинути повідомлення.

Тож якщо ви хочете надалі мати можливість надсилати пошту людям, які використовують переадресацію так, як вона працювала протягом десятиліть до появи SPF, принаймні не використовуйте -all.

Це може бути виправлено, якщо MX для b.orgвикористаних SRS або якщо MX для reallyb.orgбілих списків листів, що надходять з b.org. На мій погляд на реальність, проте більшість експедиторів не виконують жодного з цих двох. А якщо ви перебуваєте в положенні A, якщо ви думаєте про те, як впровадити SPF на своєму сервері, це загалом ви не можете контролювати.