В чем преимущество SPF HELO Identity

Некоторые возможные применения:

• Вы можете отклонить неудачную идентификацию HELO раньше времени. Поскольку команда HELO SMTP происходит в начале разговора, вы можете отклонить идентификаторы HELO, которые оцениваются как fail сразу же. (Я использую это на своем собственном почтовом узле и вижу, как довольно много клиентов, претендующих на роль этого самого почтового узла, отклоняются раньше времени.)

• Вы можете оценивать как идентификатор HELO, так и идентификатор MAIL FROM и использовать оба для получения некоторого "балла" легитимности. Например, вы можете присвоить больше доверия отправителю, чьи идентификаторы HELO и MAIL FROM оцениваются как pass.

• Вы можете решить пропустить оценку идентификатора MAIL FROM, если вас устраивает идентификатор HELO pass или fail или softfail, так сказать, в качестве сокращения: вы не обязаны проверять MAIL FROM, если он вас не интересует. Обратите внимание, однако, что идентификатор HELO может быть легко подделан, как и идентификатор MAIL FROM (отправители могут посылать все, что им заблагорассудится), поэтому обычно вас будет интересовать идентификатор MAIL FROM (и, возможно, передавать его в компонент DMARC).

Все зависит от ваших требований. Это также зависит от того, что позволяет ваша реализация SPF (все вышеперечисленное поддерживается моей собственной реализацией, SPF Milter).

На практике, возможно, стоит думать об идентификации HELO как о чем-то, что в первую очередь полезно при отрицательных результатах (fail, softfail, permerror), и не так много при положительных результатах (pass). Когда почтовый сервер проверяет идентификатор HELO и встречает отрицательный результат, он может либо сразу завершить разговор, либо записать отрицательный результат HELO как окончательный результат SPF в заголовке. При такой политике идентификатор MAIL FROM действительно не нужно оценивать в этих случаях. Такая политика действительно приведет к упомянутому сокращению ресурсов DNS, и поэтому именно здесь я вижу непосредственную практическую пользу от предоставления и проверки идентификатора SPF HELO.

Проверок HELO достаточно только «Если окончательное определение» может быть сделано в соответствии с вашей собственной цитатой из RFC. -- Это не так, если вы не доверяете домену, соединению и DNS.

Для меня загадка, почему RFC так написан.

Тем не менеея буду следить за тем, чтобы мои серверы отправляли законные идентификаторы HELO. Причина: почтовые серверы начинают отклонять письма с моего домена (подозрение в необоснованном спаме), но по-прежнему принимают законные письма, которые мои серверы правильно пересылают только на определенную учетную запись. (На этих письмах MAIL FROM SPF всегда будет завершаться ошибкой.)

Возможно, большинство почтовых подсистем пока этого не делают: но если они оценивают (мои) серверы через границы одной почты (сейчас или в будущем), я хочу, чтобы они доверяли моим доменам/серверам. Если они принимают мои переадресации и начинают доверять почте, исходящей отсюда, или если они продолжают доверять моим переадресации, потому что почта, исходящая отсюда, светит на всех проверках SPF, то я полностью на SPF.

И на принимающем конце:

Строгий отказ от обслуживания по отрицательным проверкам личности HELO означает отказ в обслуживании клиентам, не имеющим SPF. Реакция на положительные проверки HELO означает отсутствие реакции вообще, т.е. продолжение сеанса.

Итак, в заключение: возможно, идентификатор HELO SPF может служить в вашей почтовой системе как один крошечный кусочек в контроле спама и т. Д. Если это так, отлично. В моих системах это не так.