Какие-либо преимущества от добавления записи SPF для ретранслятора почты, которая не соответствует RFC5322 из домена?
При использовании службы доставки почты, такой как AWS SES или SendGrid, есть ли какие-либо преимущества от включения их записей SPF для домена в заголовок RFC5322.From (header-from)?
Поскольку они работают по умолчанию, они используют свой собственный RFC5321.MailFrom (envelope-from), который должен проверять SPF в соответствии со стандартами.
Однако мне интересно, есть ли еще преимущество, например, сломанные почтовые серверы или почтовые серверы, которые в любом случае могут проверять RFC5322.From на SPF для проверки на спам. Или просто не беспокойтесь, потому что это никогда не проверялось. Любопытно, есть ли у кого-нибудь практический опыт по этому поводу.
Например, AWS SES использует субдомен amazonses.com в RFC5321.MailFrom. В этом вопросе предполагается, что это не было изменено с помощью пользовательской настройки «ПОЧТА ОТ».
Типичная реализация проверки SPF выполняется сразу после MAIL FROM (с отклонением, возможно, инициированным после RCPT TO, чтобы сохранить больше отладочной информации в логах). Это до того, как появится какой-либо контент (DATA), включая заголовки сообщений. RFC 7208, 2.2 описывает, как следует выполнять проверку по RFC5321 MailFrom и HELO/EHLO. Также явно не рекомендуется проверять любые другие удостоверения (например, RFC5322.From) по записям SPF.
Без явного одобрения публикующего ADMD проверка других удостоверения против записей SPF версии 1 НЕ РЕКОМЕНДУЕТСЯ, потому что есть случаи, которые, как известно, дают неверные результаты.За например, почти все списки рассылки переписывают идентификатор
MAIL FROM. (см. Раздел 10.3), но некоторые не меняют никакие другие тождества в сообщение. Документы, определяющие другие личности, должны быть определить метод явного утверждения.
Политика DMARC (RFC 7489) обеспечивает такое «явное одобрение», которое далее сообщает получателю, как владелец домена хочет получить сообщения с как невыровненным SPF, так и невыровненным DKIM (RFC 6376) подпись, которую необходимо обработать. Именно DMARC защищает RFC5322.From, тогда как SPF и DKIM как таковые вообще не распознают такое выравнивание. Если какая-то система защиты от спама наказывает невыровненные сообщения без явного одобрения, это проблема на их стороне и не следует пытаться решить ее с помощью нестандартных записей SPF, как вы предлагаете.
Проблема, описанная в цитате, остается с DMARC, потому что, если сообщение было перенаправлено...
- с исходным
MAIL FROM, оно не выдержало бы проверку SPF. - с переписанным
MAIL FROMон не переживет выравнивание DMARC.
По этой причине рекомендуется использовать DKIM с DMARC, так как он лучше переносит пересылку. Кроме того, кто-то, кто хочет опубликовать p=reject (или даже p=quarantine), должен сначала приложить некоторые усилия для настройки всех возможных законных отправителей, соответствующих либо DKIM, либо SPF — рекомендуется с оба.
Например.с Amazon SES это означает настройку пользовательского MAIL FROM домена: добавление поддомена с их MX и записями SPF. Для этого также требуется расслабленная политика DMARC, которая разрешает выравнивание, если совпадает организационный домен, как определено в RFC 7489 3.1.