Чому електронну пошту доставляють звичайно, незважаючи на те, що "SPF" не відповідає "?

Я намагаюся з’ясувати, чому підроблений електронний лист надходить до основних постачальників електронної пошти (gmail.com, outlook.com), хоча електронний лист позначений SPF hardfail. Електронний лист також доставляється Microsoft Exchange, який передає PermErrorтой самий запис SPF.

Я надсилаю електронний лист за допомогою домену SOME_DOMAIN.com, який визначає пошкоджений запис SPF. Електронний лист надсилається з моєї власної IP-адреси, яка явно не вказана в записі SPF SOME_DOMAIN.com. Запис SPF для SOME_DOMAIN.com має такі три властивості, перші два є порушенням SPF RFC-4408:

1. Для вирішення всього запису SPF потрібно через 10 запитів DNS include:.
2. Помилка синтаксису в одному із записів SPF, python-spf видає помилку розбору.
3. Запис SPF містить і правила, ~allі -allобидва кажуть, що набір усіх адрес повинен softfailіhardfail

Електронний лист, надісланий на адресу outlook.com, що вказує себе на адресу admin@SOME_DOMAIN.com, міститиме таку помилку у заголовку SMTP, що надсилається. Цей електронний лист зазвичай доставлявся у вхідні повідомлення користувача :

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail також доставить електронну пошту у папку "Вхідні" користувача, але видасть іншу помилку SPF:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

То що тут відбувається? Чому електронна пошта доставляється незважаючи на SPF hardfail? Чи означає, що зламаний запис SPF означає, що інші SMTP-сервери повністю ігнорують SPF? Або щось тут мені не вистачає ...

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

Умови помилки SPF нічого не вказують на потрібну політику. Як такий, вони не дають ніяких вказівок щодо того, приймати це повідомлення чи ні. Не виключено, що політика задумана +all. В цьому випадку нормально приймати пошту. Здається, Google поблажливий, якщо ці домени не відповідають стандарту.

Навіть відхилення політики SPF ( -all) є ненадійними під час перевірки адрес відправника. Існує ряд випадків, коли відхилення такої пошти було б недоцільним, зокрема:

• Пошта, яку надсилають контрактники (ці люди отримують гроші за порушення політики.);
• Пошта, що надсилається з веб-форм та іншої такої автоматизованої системи;
• Електронна пошта, що пересилається списками розсилки або іншими механізмами переадресації; і
• Просто помилкова конфігурація записів SPF (не часто, але не досить рідко).

Я запускаю досить невеликий сервер, де я можу відкласти на жорсткі помилки. Це дозволяє мені перелічити законні збої в білому списку. Якщо відправник помітить, що повідомлення не доставлено, він може виправити їх конфігурацію. У деяких випадках я спробую зв’язатися з відповідними postmaster, але багато доменів не мають postmasterадреси.

Користувачі, які хочуть застосувати більш чітку політику, можуть використовувати DMARC, який ще не є стандартом. Пошта, як і раніше, буде доставлена, але може бути підкарантована або відхилена, як зазначено в цій політиці. Пошта, яка не відповідає політиці, може бути доставлена ​​в папку зі спамом, а не у звичайну папку "Вхідні".

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

Багато поштових серверів не мають запису SPF. Якщо поштовий сервер не має SPF-запису, я перевіряю, чи немає у батьківського домену запис SPF. Це нестандартно, але ефективно. Я закликаю адміністраторів електронної пошти переконатися, що існує IP-запис SPF для IP-серверів, як зазначено в записі PTR. Ваш сервер повинен ідентифікувати себе за ім'ям, поверненим також його записом PTR. Перевірте, чи є у вас відповідний запис для зворотної перевірки DNS.