Как это письмо подрывает проверки SPF?


13

Я запускаю почтовый сервер, который, по-видимому, корректно обрабатывает электронные письма с установленным SPF - однако я начал получать поддельные электронные письма, якобы отправленные из банка - с адресом «От», установленным в качестве банка, - но они определенно не происходят из банка.

Соответствующие заголовки письма:

Delivered-To: me@mydomain.name
Received: from mail.mydomain.org (localhost [127.0.0.1])
    by mail.mydomain.org (Postfix) with ESMTP id AD4BB80D87
    for <user@mydomain.com>; Thu, 13 Oct 2016 20:04:01 +1300 (NZDT)
Received-SPF: none (www.tchile.com: No applicable sender policy available) receiver=mydomain.org; identity=mailfrom; envelope-from="apache@www.tchile.com"; helo=www.tchile.com; client-ip=200.6.122.202
Received: from www.tchile.com (www.tchile.com [200.6.122.202])
    (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
    (No client certificate requested)
    by mail.mydomain.org (Postfix) with ESMTPS id 40F6080B9F
    for <user@mydomain.com>; Thu, 13 Oct 2016 20:03:57 +1300 (NZDT)
Received: from www.tchile.com (localhost.localdomain [127.0.0.1])
    by www.tchile.com (8.13.1/8.13.1) with ESMTP id u9D73sOG017283
    for <user@mydomain.com>; Thu, 13 Oct 2016 04:03:55 -0300
Received: (from apache@localhost)
    by www.tchile.com (8.13.1/8.13.1/Submit) id u9D73smu017280;
    Thu, 13 Oct 2016 04:03:54 -0300
Date: Thu, 13 Oct 2016 04:03:54 -0300
Message-Id: <201610130703.u9D73smu017280@www.tchile.com>
To: user@mydomain.com
Subject: CANCELLATION_PROCESS.
From: KIWI BANK <noreply@kiwibank.co.nz>
Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=029F3E3270D5187AA69203962BF830E3
X-Virus-Scanned: ClamAV using ClamSMTP

Ключевым моментом здесь является то, что kiwibank.co.nz является законным, уважаемым банком, откуда я родом, и имеет запись SPF, которая гласит:

kiwibank.co.nz.     13594   IN  TXT "v=spf1 include:_spf.jadeworld.com ip4:202.174.115.25 ip4:202.126.81.240 ip4:202.12.250.165 ip4:202.12.254.165 ip4:66.231.88.80 include:spf.smtp2go.com include:spf.protection.outlook.com -all"

Итак, после некоторого прочтения - кажется, что Envolope-From верен, но «От» было подделано. Есть ли способ, которым я могу исправить / смягчить это, не нарушая "общую" электронную почту? Я отмечаю, что я использую Postfix, Spamassassin и policyd (postfix-policyd-spf-perl) - и если его действительно так легко обойти, какой смысл в SPF?

Ответы:


13

В этом случае они, вероятно, сказали вашему серверу что-то вроде этого:

EHLO www.tchile.com
MAIL FROM: apache@www.tchile.com 
RCPT TO: user@mydomain.com
DATA
Date: Thu, 13 Oct 2016 04:03:54 -0300
Message-Id: <201610130703.u9D73smu017280@www.tchile.com>
To: user@mydomain.com
Subject: CANCELLATION_PROCESS.
From: KIWI BANK <noreply@kiwibank.co.nz>
Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=029F3E3270D5187AA69203962BF830E3
X-Virus-Scanned: ClamAV using ClamSMTP

The contents of mail...
.

Разговор SMTP (он же «конверт») может отличаться от заголовка письма. SPF не проверяет заголовок, однако это всегда заголовок, который фактически отображается конечному пользователю! Да, SMTP является , что сломано. Да, SPF это , что сломано.

Вам лучше всего будет проверять DMARC вместо проверки SPF. По умолчанию DMARC проверяет SPF, но также проверяет выравнивание заголовка From с SMTP MAIL FROM (домены должны совпадать - игнорирует часть имени пользователя). В качестве бонуса вы также можете получить поддержку DKIM, которая является очень полезным дополнением к SPF.

DMARC будет зависеть от записи DNS TXT, установленной на _dmarc.kiwibank.co.nz. но в настоящее время нет ни одного. В соответствии с текущим состоянием интернет-правил это означает, что владелец kiwibank.co.nz. не заботится о том, чтобы быть защищенным от таких подделок. Но в некоторых реализациях вы можете использовать DMARC для всех входящих писем.


SPF не сломан. Сама почта здесь сломана. Конверт в! = Заголовок имеет веские причины. Междоменный конверт из заголовка! = Не имеет веских причин.
Джошудсон

1
@ Джошудсон, да, это так. Например, если я настроил .forwardфайл (или другую переадресацию электронной почты) для пересылки из одной из моих учетных записей в другую, имеет смысл сохранить, от кого пришло сообщение (Из заголовка), и отобразить его как от кого оно в почтовый клиент и т. д. Но любые отскоки, генерируемые этой пересылкой (отправителем конверта), должны отправляться мне, а не тому человеку, который первоначально отправил сообщение. То же самое относится и к спискам рассылки.
Дероберт

1
Списки рассылки @derobert являются незначительными. Почтовые клиенты не предупреждают пользователей об очевидной подделке - это огромная проблема, и никакое .forwardиспользование не может ее оправдать.
kubanczyk

Это просто невероятно.
g33kz0r

2

Итак, после некоторого прочтения - кажется, что Envolope-From верен, но «От» было подделано. Есть ли способ, которым я могу исправить / смягчить это, не нарушая "общую" электронную почту?

Проверка Fromзаголовка будет разбить списки рассылки:

  1. foo @ yourbank отправляет письмо на адрес cat-picture-shared-list @ bar.

  2. Список рассылки примет почту,

    • заменить на Envelope-Fromчто-то похожее на cat-picture-share-list-bounce @ bar,
    • возможно изменить заголовок Reply-To и
    • повторно отправить письмо всем получателям (например, вам).

Теперь ваш почтовый сервер получает почту с

Envelope-From: cat-picture-sharing-list-bounce@bar
From: foo@yourBank

отправлено с почтовых серверов бара.

Я отмечаю, что я использую Postfix, Spamassassin и policyd (postfix-policyd-spf-perl) - и если его действительно так легко обойти, какой смысл в SPF?

  1. Многие спаммеры не удосуживаются отправить «правильный» конверт-From.
  2. Ваш банк не получит (большую часть) обратного рассылки для этой спам-почты, поскольку отчеты о недоставке (или: должны быть) отправлены на адрес Конверта-От.
  3. Оценка на основе Envelope-From становится более надежной. Если вы (или доверенный поставщик скоринга) присваиваете всем сообщениям с Envelope-From = ... @ yourbank крайне отрицательный балл за спам, спаммеры не могут этим злоупотреблять.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.