> host -t txt sberbank.ru
sberbank.ru descriptive text "v=spf1 mx mx:shark11.sberbank.ru mx:shark12.sberbank.ru mx:shark13.sberbank.ru mx:shark14.sberbank.ru mx:email1.sberbank.ru -all"
Счастливый финал: в течение дня запись исправили, теперь она соответствует RFC.
> host -t txt sberbank.ru
sberbank.ru descriptive text "v=spf1 mx -all"
Ну, а для тех кто осилит прочитать — добро пожаловать под кат.
Зачем нужен SPF?
SPF помогает бороться с подделкой адресов отправителя. Не путайте SPF c DMARC, SPF позволяет только установить, мог ли данный IP-адрес отправлять почту от имени вот того домена (с поддержкой целого ряда исключений и реверансов).
Существует мнение, что SPF не нужен и вреден, однако как показывает практика, SPF на сегодня есть основной механизм в DMARC и пока на горизонте ничего подобного нет.
Как это работает?
Почтовый сервер, принимая почту, смотрит на адрес отправителя, а потом идет и запрашивает у домена отправителя особые записи, где на хитром языке сформулировано, какой IP может слать почту этого домена, а какой нет. В результате принимается решение, принимать ли данное письмо или нет, а может быть принять и посчитать спамом.
И что, реально работает?
Ну, в целом, не совсем. Изначально в SPF был предусмотрен тип записи, который позволяет делать Softfail. Это как бы косяк, но простительный. То есть, я говорю, что почта от моего домена может идти с вот этих адресов, тогда она точно нормальная. И если с каких-то других, то это ничего, простительно.
Вот эта извинительная приписка вообще на сегодня практически сводит к нулю толк от SPF, поскольку спамеры часто в эту извинительную приписку попадают.
В чем Сбербанк молодец?
А в том, что у них запись содержит -all, это как раз недопущение извинительного Softfail. То есть, ребята из Сбера как бы говорят нам, что почта от них может идти только с заданных адресов и никак иначе. Молодцы, это здорово.
А в чем же Сбербанк ошибся?
А в том, что запись у них сформулирована неверно. Это вызывает ошибку Permerror, и тогда у большинства почтовых систем запись даже не проверяется, а письмо просто пропускается.
Согласитесь, глупо делать -all, жесткую запись и при этом допускать ошибку, делая всю запись некорректной.
Да где же ошибка?
RFC 7208 вводит некоторые ограничения на количество DNS-запросов, которые должен сделать почтовый сервер, чтобы получить нужные данные в SPF. Оно же самое RFC ограничивает количество запросов с пустым результатом или ошибкой.
Разбираем запись:
"v=spf1 mx mx:shark11.sberbank.ru mx:shark12.sberbank.ru mx:shark13.sberbank.ru mx:shark14.sberbank.ru mx:email1.sberbank.ru -all"0. v=spf1
Версия SPF-записи, т.е. синтаксис
1. mx
Почту от домена sberbank.ru могут отправлять только те серверы, что перечислены, как MX
> host -t mx sberbank.ru
sberbank.ru mail is handled by 50 shark11.sberbank.ru.
sberbank.ru mail is handled by 50 shark14.sberbank.ru.
sberbank.ru mail is handled by 50 email1.sberbank.ru.
sberbank.ru mail is handled by 50 shark12.sberbank.ru.
sberbank.ru mail is handled by 50 shark13.sberbank.ru.Хорошо, видим эти пять серверов.
2. mx:shark11.sberbank.ru
Почту от домена sberbank.ru могут отправлять те серверы, что перечислены, как MX для домена shark11.sberbank.ru
СТОП! Ещё раз.
Почту от домена sberbank.ru могут отправлять те серверы, что перечислены, как MX для домена shark11.sberbank.ru
> host -t mx shark11.sberbank.ru
shark11.sberbank.ru has no MX recordИ вот этот результат засчитывается, как пустой. А по RFC, после первых двух таких ошибок надо прекратить анализировать SPF-запись и посчитать ее ошибочной. Что и происходит.
Короче говоря, ребята немного перестарались.
Как надо было сделать?
"v=spf1 mx -all"А может коллеги сделали лучше?
На самом деле, сам Сбербанк редко шлет письма, вернее, в нашей почтовой системе их, например, не так много. Гораздо больше их приходит от площадки «Сбербанк АСТ», давайте посмотрим туда.
> host -t txt sberbank-ast.ru
sberbank-ast.ru descriptive text "v=spf1 mx a:mail2.sberbank-ast.ru a:mail3.sberbank-ast.ru a:mail4.sberbank-ast.ru a:gw.sberbank-ast.ru a:mail7.sberbank-ast.ru ~all"А тут, увы, Softfail. Что сводит к нулю ценность SPF-записи.
UPDATE
Коллеги из «Сбербанк АСТ» отреагировали быстро. Теперь вот так:
> host -t txt sberbank-ast.ru
"v=spf1 mx a:mail2.sberbank-ast.ru a:mail3.sberbank-ast.ru a:mail4.sberbank-ast.ru a:gw.sberbank-ast.ru a:mail7.sberbank-ast.ru -all"По сути, конечно, несколько избыточно, поскольку есть указание mx и
> host -t mx sberbank-ast.ru
sberbank-ast.ru descriptive text sberbank-ast.ru mail is handled by 5 mail4.sberbank-ast.ru.Но переключение с ~all на -all достойно всяческой похвалы.
Комментарии (43)
torkve
16.08.2016 12:26Знаю, что шансов мало (я их и сам когда-то просил включить HSTS на online.sberbank.ru, о чём получил классический ответ ни о чём), но вы всё-таки попробовали бы написать им в саппорт.
kvaps
16.08.2016 12:30Ух ты, это вы ловко нашли! За статью спасибо, ошибка действительно достойна огласке.
Интересно, если указать тупо ip-адреса, запись работать будет?
artemlight
16.08.2016 13:31Любая пересылка будет сводить ценность SPF-записи к нулю.
А касательно сбербанка — вся действительно ценная переписка с ними идёт через клиент-банк. В том числе — и для физлиц.
prometheus_ru
16.08.2016 13:33SRS отлично работает, поэтому первое утверждение неверно.
А вот по поводу действительно ценной переписки — не забывайте, что фишинг никто не отменял. Банку жить без -all нельзя.pansa
17.08.2016 00:51Посмотрел топ10 банков, жесткий -all прописан только у 4, включая Сбер.
У остальных или ~all или вовсе не прописана SPF.
Как же они так? И есть ли вообще какая-то реакция на письма, попадающие в эту «извинительную приписку», там, пропустить, но накинуть немного спам-очков? Если этот механизм такой хороший, зачем бояться прописывать "-all"? Что-то тут не чисто.prometheus_ru
17.08.2016 00:55Да в этом и проблема, что накидывание спам-очков крайне осложнено. Из моего опыта достаточного количества почты в сутки, с Softfail ее достаточно много, порядка 40%. Всем накидывать не будешь.
SRS да, у многих не работает (см. ниже mail.ru) или работает некорректно. В результате от страха перед некорректной пересылкой (который больше малюют, чем он есть на самом деле) все пишут ~all, так, на всякий случай.
Как результат, имеем что имеем.pansa
17.08.2016 01:17А откуда так много нормальной-ненормальной почты, из-за пересылок? Т.е spf де-факто не работает (хотя задумка хорошая)?
Вон и гмейла даже: «v=spf1 include:_spf.google.com ~all»prometheus_ru
17.08.2016 01:18Специально посмотрел, правда, без глубокого анализа. Практически один спам у меня идет в Softfail.
Вернее, я допускаю, что там есть легитимная пересылаемая почта. Но крайне мало.
xBrowser
16.08.2016 14:40Сбербанк для рассылок пользуется сторонними сервисами. Меня спамят от sendsay.ru
Сложно сказать, какая SPF запись была на момент ноября 15 года на sberbank.ru, но проверку spamassassin`а прошла:
Заголовки письма от sberbank.ruReceived-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=194.186.207.32; helo=shark13.sberbank.ru; envelope-from=sberbank@modified.mail; receiver=my@modified.mail
Received: from Shark13.sberbank.ru (shark13.sberbank.ru [194.186.207.32])
by mail.modified.domain (Postfix) with ESMTPS id 3C7451E058D
for <my@modified.mail>; Mon, 16 Nov 2015 15:40:00 +0300 (MSK)
Received: from SPRING11.sigma.sbrf.ru (10.21.7.66) by Shark13.sberbank.ru
(10.21.6.32) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 16 Nov 2015
15:36:35 +0300
Received: from Ocean16.sigma.sbrf.ru ([fe80::1480:e5a9:4888:1b2f]) by
spring11.sigma.sbrf.ru ([::1]) with mapi id 14.03.0248.002; Mon, 16 Nov 2015
15:34:43 +0300
From: <sberbank@modified.mail>
To: <my@modified.mail>
Date: Mon, 16 Nov 2015 12:34:42 +0000
Message-ID: <Ocean16.sigma.sbrf.ru>
Accept-Language: ru-RU, en-US
Content-Language: ru-RU
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.6.242]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset=«windows-1251»
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-KSE-AntiSpam-Interceptor-Info: internally-submitted e-mail
Endru9
17.08.2016 09:07Теперь не смогут отправлять отправлять через sendsay, если не добавят запись в SPF. вообще имея большую аудиторию клиентов, не хорошо использовать сторонние сервисы для рассылок!
prometheus_ru
17.08.2016 09:08Ну в комментарии приведен кусочек рассылки, которая не шла через sendsay.
А вообще, для сторонних сервисов внесут исключения, нет проблем.
xBrowser
17.08.2016 18:09Да, надо было сразу пояснить про рассылку. Она, естественно, имеет другой источник и сбербанковская SPF не используется. Письмо приходит с «левого» домена. Для того чтобы представиться правильно подставляется поле From: <vip@sberbank.ru>. SPF проверяется у gluck@mail.sendsay.ru и он естественно проходит проверку. Стандартный почтовый финт. Письмо даже под пристальным просмотром в почтовом клиенте не выдаст отправителя. Везде красуется только сбербанк.
SPF запись mail.sendsay.ruhost -t txt mail.sendsay.ru
mail.sendsay.ru descriptive text "v=spf1 include:spf.sendsay.ru -all"
host -t txt spf.sendsay.ru
spf.sendsay.ru descriptive text "v=spf1 +ip4:81.9.34.128/25 +ip4:81.222.129.0/24 +ip4:81.222.217.0/24 +ip4:81.222.133.0/24 +ip4:81.9.46.0/24 +ip4:185.138.180.0/22 +ip4:185.76.232.0/22 +ip6:2a07:b40::/29 +ip6:2a05:5dc0::/29 ?all"
ildarz
16.08.2016 15:16> Это вызывает ошибку Permerror, и тогда у большинства почтовых систем запись даже не проверяется, а письмо просто пропускается.
Это не так.
Во-первых, запись таки проверяется (нельзя выявить ошибку в записи, не проверив её, правда?).
Во-вторых, механизмы в записи проверяются слева направо. Это означает, что в случае валидной почты от Сбера письмо пройдет успешную проверку по механизму «mx».
В-третьих, если почта пришла с невалидного хоста, то действительно дальше пойдут пустые запросы, однако стандарт рекомендует возвращать permerror после пары таких, а не обязывает. Учитывая, что этот RFC относительно свежий и абсолютное большинство имплементаций почтовых серверов разрабатывались и внедрялись до его публикации — утверждение «у большинства почтовых систем… письмо просто пропускается» нуждается, как минимум, в дополнительном обосновании.prometheus_ru
16.08.2016 15:22Во-первых, запись таки проверяется (нельзя выявить ошибку в записи, не проверив её, правда?).
Результатом проверки такой записи является Permerror. Давайте возьмем конфиг policyd-spf.conf из Ubuntu 16.04 и посмотрим туда.
# A permanent error has occured (eg. badly formatted SPF record)
PermError_reject = False
Т.е. никакого Reject не будет, письмо пойдет дальше. Кроме того, обычно работа с SPF не есть работа почтового сервера. В подавляющем большинстве случаев это делается некой внешней утилитой (неважно, как вызываемой), которая вполне себе может поддерживать RFC 7208 от 2014 года.
SHOULD, написанный в RFC, воспринимается, как рекомендация. Однако, я не вижу никаких причин ей не следовать.
Вообще, если посмотрите, то политика в отношении SPF-проблем крайне мягкая, это если брать конфиги по-умолчанию. У Сбера же применяется -all, что означает «жестить и никаких гвоздей».ildarz
16.08.2016 16:04+1> Результатом проверки такой записи является Permerror.
Ещё раз — это не так. Для валидного письма будет pass. Для невалидного — permerror, но только в том случае, если принимающая сторона зачем-то имплементирует рекомендации свеженького RFC, не оглядываясь на окружающий мир, который много лет до его появления жил по другим правилам.
> Давайте возьмем конфиг policyd-spf.conf из Ubuntu 16.04
Зачем? Какой процент почтовых серверов в мире работает на дефолтном конфиге Ubuntu 16.04? Плюс речь совершенно не о том, как реагировать на permerror, а о том, будет ли этот permerror вообще, или парсер всё-таки сделает больше двух запросов и вернет fail.
> SHOULD, написанный в RFC, воспринимается, как рекомендация. Однако, я не вижу никаких причин ей не следовать.
Вы можете видеть или не видеть, но «большинство» почтовых систем, поведение которых вы пытаетесь предсказать, разработано и сконфигурировано не вами.
SHOULD — This word, or the adjective «RECOMMENDED», mean that there may exist valid reasons in particular circumstances to ignore a particular item
Возможно, «много лет рекомендации RFC были иными» — для вас не valid reason, но вот за других я бы говорить не взялся. Не говоря уж о том, что выход нового RFC сам по себе совершенно не приводит к тому, что все внезапно бросились переписывать свои парсеры.prometheus_ru
16.08.2016 16:26Я же говорю еще раз, проверка SPF — это обычно дело внешней сущности. Которая может (и нужет) обновляться.
Про «большинство» не вижу смысла спорить, поскольку ни Вы, ни я не сможем доказать друг другу, как будет настроено то самое «большинство».ildarz
16.08.2016 17:03+2> поскольку ни Вы, ни я не сможем доказать друг другу, как будет настроено то самое «большинство».
Разница в том, что вы позволяете себе делать утверждения насчет этого большинства, на самом деле вообще ничего о нем не зная. Спорить в этом случае действительно смысла нет — надо либо проверять то, что утверждаете, либо не выдавать придуманное за действительное. Технически верной фразой было бы что-то типа «SPF-запись Сбера корректно проходит проверку в случае валидного письма, но поддельное письмо, в соответствии с текущим стандартом и в зависимости от имплементации стандарта конкретным почтовым сервисом, может давать результат проверки permerror и пропускаться как валидное».
mrdoger
16.08.2016 15:36Сбербанк-АСТ видимо поправили
host -t txt sberbank-ast.ru sberbank-ast.ru descriptive text "v=spf1 mx a:mail2.sberbank-ast.ru a:mail3.sberbank-ast.ru a:mail4.sberbank-ast.ru a:gw.sberbank-ast.ru a:mail7.sberbank-ast.ru -all"prometheus_ru
16.08.2016 15:40Да, и правда поправили. Немного избыточно, правда.
> host -t mx sberbank-ast.ru
sberbank-ast.ru mail is handled by 5 mail4.sberbank-ast.ru.
Тогда mail4 можно было бы не добавлять в список.
Но -all радует. Это хорошо.tbp2k5
16.08.2016 23:29+1Честно говоря так и не понял вашей радости от "-all"… Объективная польза от SPF близка к гомеопатической. Прописывать ее конечно нужно, а вот выставлять "-all" я бы не советовал…
Интересно, а они (sberbank-ast.ru) понимают что после этой «правки» часть их клиентов начнет терять их письма (например при пересылке после смены провайдера/работы)?prometheus_ru
16.08.2016 23:32Для случаев пересылки есть SRS, который вполне себе хорошо работает. Если пересылающий не умеет им пользоваться, то ССЗБ.
Если Вы еще ни разу не попадали в spamcop только потому, что ответили «нет такого пользователя» на спам от домена, у которого стоит -all, то все еще впереди.
Ну и про гомеопатию. На почтовой системе с примерно 200 тысячами сообщений в сутки в Fail по SPF уходит порядка 6-7%. Это крайне интересная цифра. Разумеется, что пересылки среди этих сообщений мизер, а вот спамеров — за 95%.tbp2k5
17.08.2016 00:41Спасибо за быстрый ответ. Отвечу по пунктам:
SRS и прочее из этой фразы: вы забываете что такое интернет — в нем не принято устраивать революции. Если вы имплантируете новый стандарт то совместимость с существующими системами ваша проблема а не проблема всех остальных. Впрочем я не исключаю что в вашей деятельности вы можете себе позволить потерять часть пользователей/клиентов. Важно лишь понимать что вы делаете…
SpamCop: ну уж лет 15 не попадал хотя всем отвечаю «нет такого пользователя» если «нет такого пользователя». Там по-моему вполне адекватные ребята. Я с ними как раз пытаюсь переписываться последнее время: наши «коллеги» спамеры научились слать мейлы с поломанными хедерами которые обманывают их парсер… В вашем комментарии вы наверное хотели сослаться на кого-то другого…
200 тысячами сообщений в сутки: тоже глянул у себя на MXах — 438000 коннектов за последние 24 часа, 34000 письма пропущено для дальнейшей «контекстной» фильтрации (в ней и SPF учитывается)… Но собственно я отвлекся. То что я хотел сказать: посмотрите другие способы борьбы со спамом:
Опираться на SPF бессмысленно и бесполезно… Будет как с Greylisting-ом: как только заметное количество узлов начнет реально (с нормальным весом) учитывать SPF спамеры перестанут лениться его прописывать. А тем временем, вы, с вашим "-all", реально теряете связность с частью пользователей… Получаете-ли вы что-либо в замен...? Не уверен… (собственно причина моего начального скептицизма)prometheus_ru
17.08.2016 00:47Спасибо за развернутый ответ.
Что Вы, разумеется, что я не считаю SPF методом борьбы со спамом. В первую очередь, борьбой с фишингом.
Во вторую очередь это можно считать борьбой со спамом, но с рядом оговорок.
Борьбу со спамом я делю на две большие задачи. Первая — это борьба на бордере, т.е. еще на этапе приема. Когда мы ничего не знаем про того, кто будет получать это письмо. Когда мы ничего не знаем про его спам фильтры. Наша задача — быстро устроить деление на «хорошее» и «плохое». (Плохое, кстати, необязательно реджектить, можно в грейлист отправлять).
В первой задаче SPF хорошо работает. Быстро отсекаем Fail, вайтлистим Pass (кроме тех, у кого +all, тех наказываем), подвергаем мукам Softfail.
А вот вторая задача — это уже спам-фильтрация с учетом того, от кого и кому доставлено письмо. Тут уже другие методы, но если кратко, то тут SPF абсолютно бесполезен. Вот как-то так.
А про SpamCop — на полном серьезе. Несколько абуз от сайтов, у которых стоит -all, что я им ответил «Нет такого пользователя» на спам.tbp2k5
17.08.2016 01:56Мой опыт/ощущение «фишинга» — если в вкратце — техника тут бессильна: пользователи заполняют формуляры и кликают на ссылки в письмах которые, мне кажется, даже в пятном угаре нельзя принять за настоящие. Недавно то-ли на семинаре то ли в частной обсуждении слышал любопытную гипотезу:
Фишеры специально оставляют массу «аномалий/ошибок» в своих письмах/формулярах — это психологический прием позволяет отсечь «слишком умных» — их трудно «разводить», они могут поднять тревогу, и.т.д.
SpamCop: странно, в любом случае DSN — обязательная часть «почтовых» RFC, а SPF — расширение для любителей, так что я уверен что вам ничего не грозит. Меж-делом тут подумал: мне SpamCop шлет ARF/report на отдельный адрес, вы у них зарегистрированы? Или может письма не напрямую от них были?
prometheus_ru
17.08.2016 02:02Про фишинг соглашусь, но мое мнение, что зловредам нужно максимально усложнить жизнь. SPF тут помогает.
Про SpamCop: мы с ними общаемся напрямую, на адрес noc пишут. А про DNS — посмотрите тут последние три вопроса-ответа. Очень забавляет :)tbp2k5
17.08.2016 02:30Помню их FAQ, читал. Но они про DSN то и пишут — может быть «злом» но тем не менее это часть стандарта. Лет 5-10 было у меня пару запросов на эту тему (может и от них уж не помню сейчас). Ответил кратко «DSN is mandatory part of RFC.» и развернуто «если проблема столь острая можете делать по простому: дискардить любые входящие ДСНы (глупость), или можете делать по интеллектуальному: дискардить входящие ДСНы для которых нет соответствующих исходящих писем». Если проблема может быть решена на стороне клиента то там она и должна решаться…
tangro
16.08.2016 19:29+9Пишут в правилах Хабра, что «Хабр — не жалобная книга», но де-факто Хабр — вообще единственная стабильно работающая жалобная книга рунета. Описанную здесь ошибку пофиксят с вероятностью около 100%.
prometheus_ru
16.08.2016 23:02Вы совершенно правы, в течение дня изменения внесли. Хотя на мое письмо так и не ответили. Шапку поста обновил.
slonopotamus
16.08.2016 21:37+1Ну так и почему у Сбербанка некорректная SPF-запись для домена? Вы рассказали в чем заключается некорректность, но на вопрос «почему» так и не ответили.
prometheus_ru
16.08.2016 22:58Вы задали прекрасный вопрос. Признаюсь, я ожидал его раньше :)
У меня есть несколько вариантов. Приведу их по мере повышения режима параноика.
1. Банальная глупость и желание «сделать лучше». Так бывает, когда люди, например, по непонятной причине включают firewall на системе, где закрывать нечего. Так и тут — перепутали семантику a c mx, вот и получилось. Либо меняли mx, и в какой-то момент накосячили.
2. Кому-то это было нужно. Формально запись выглядит правильной, а вот кто-то мог и фишить при помощи этого. Отличное прикрытие.
lehha
16.08.2016 22:36+2-all для SPF выявляет интересную багофичу у mail.ru — при переадресации почты с mail.ru «куда-нибудь», они оставляют адрес отправителя исходным, а сервер получателя видит соединение с почтового сервера mail.ru и -all в SPF, где этот сервер не обозначен. В итоге ящик-получатель после такой переадресации просто не получает письмо и режет его как спам.
BHYCHIK
17.08.2016 13:17Это общеизвестная проблема SPF. Чинится она внедрением SRS. Однако он на данный момент не имеет статус стандарта, а является только черновиком. Его реализация может испортить репутацию домена, поэтому многие (в том числе gmail: https://support.google.com/mail/answer/175365?hl=en) не рекомендуют его использовать в последнее время. Для верификации писем рекомендуется использовать DMARC, использование только SPF очень часто приводит к False Positive.
Тем не менее, спасибо за репорт. В одном из следующих релизов мы проведем тестирование SRS.
balamut108
17.08.2016 11:18Я думаю жопа у кого-то сейчас красная, так опозориться на всю страну. Может другие домены тоже проверить? :)
XolodIT
17.08.2016 14:44>Почту от домена sberbank.ru могут отправлять только те серверы, что перечислены, как MX
Может ввести в недопонимание. MX запись говорит почтовику адрес куда передать письмо для дальнейшей доставки в ящик домена получателя, это принимающий почтовый шлюз. И указывается по сути зачем? Затем чтобы при приёме почты проверить, что ip отправителя имеется среди указанных в spf MX записях и далее принять решение, начать приём почты или отклонить с какой-либо резолюцией.
Поэтому я бы переформулировал так:
Почту от домена sberbank.ru могут отправлять только те серверы, чьи ip совпадают c ip, которые DNS получит разрешив домены указанные в spf: mx, mx:domain, mx:domain/cidr.
AlexeevEugene
Походу у сбербанка еще и dkim нет))