Чи сигналізує “~ all” посеред запису SPF в кінці запису під час його розбору?

Формат запису SPF нашої компанії такий:

"v = spf1 включає: _spf.google.com ~ all a mx ip4: XX0.0 / 23 include: spf.example.com? all"

Таким чином, у нас є "~ всі" в середині нашого запису SPF. На веб-сайті openspf.com вони говорять про механізм "усі":

Цей механізм завжди відповідає. Зазвичай це відбувається в кінці запису SPF.

Отже, вони не кажуть, що "ВСЕ" МОЖЕ піти наприкінці запису SPF, але це НАЗАГАЛЬНО в кінці.

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

Мені цікаво, чи може це "~ всі" безпосередньо після включення для Google Apps (_spf.google.com) спричинити зупинку розбору та не розпізнати решту фрагментів запису SPF? Чи буде проходження проти м'якого відмови залежати від того, хто їх аналізує, і від їх конкретної реалізації того, як вони обробляють записи SPF? Чи є якась причина мати механізм "все", який не знаходиться в кінці запису SPF?

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

RFC 7208 § 5.1 про це явно: після того, як allз'явиться, все після нього ОБОВ'ЯЗКОВО проігнорувати.

Механізми після "всіх" ніколи не перевірятимуться. Механізми, перелічені після "усіх", ПОВИННІ ігнорувати. Будь-який модифікатор "перенаправлення" ( Розділ 6.1 ) ОБОВ'ЯЗКОВО ігнорувати, коли в записі є механізм "усі", незалежно від відносного впорядкування термінів.

RFC 4408 , який він застарів , сказав про те саме; новіша версія RFC просто роз'яснює наміри.

Механізми після "всіх" ніколи не перевірятимуться. Будь-який модифікатор "перенаправлення" ( Розділ 6.1 ) не має ефекту, коли існує механізм "усі".

Отже, відповідні реалізації SPF повністю ігнорують усе після першого ~all. Однак це не означає, що кожна реалізація відповідає специфікації. Зокрема, це, мабуть, вважалося гідним роз'яснення саме тому, що одна чи декілька реалізацій не відповідали.

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

"v = spf1 включає: _spf.google.com ~ all a mx ip4: XX0.0 / 23 include: spf.example.com? all"

каже по порядку:

"електронний лист, що передає запис SPF _spf.google.com, дійсний для нашого домену"

"softfail для всіх інших відправників для нашого домену"

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

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

"електронна пошта, що надходить із діапазону IP x.x.0.0/23, дійсна для нашого домену"

"електронний лист, що передає запис SPF spf.example.com, дійсний для нашого домену"

"повідомлення електронної пошти від усіх інших відправників для нашого домену не може бути підтверджено так чи інакше"

У синтаксисі запису:

Механізми оцінюються по порядку. Якщо жоден механізм чи модифікатор не відповідають, результатом за замовчуванням є "Нейтральний".

Тож для вашого, як тільки він потрапить на "softfail для всіх інших", що насправді йдеться про це ... слід ігнорувати решту механізмів, які ви вказали.

Ваш запис SPF повинен бути максимально стислим. Я дуже сумніваюся, що у вас є ціла / 23 мережа, яка повинна надсилати електронний лист для вашого домену, а також не всі ваші записи A. Можливо, так ... але, швидше за все, ні.

Гарний чистий запис SPF повинен виглядати приблизно так:

"v = spf1 включає: _spf.google.com включає: spf.example.com mx -all"

В основному це означає, що _spf.google.com, spf.example.com та ваші записи MX - єдині дійсні відправники для вашого домену ... все інше слід трактувати як недійсне.

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

Джерело: RFC7208 (див. Стор. 17)