Jak ten e-mail obala kontrole SPF?


13

Pracuję na serwerze pocztowym, który wydaje się poprawnie obsługiwać wiadomości e-mail z zestawem SPF - jednak zacząłem otrzymywać fałszywe wiadomości e-mail rzekomo z banku - z adresem Od ustawionym jako bank - ale które zdecydowanie nie pochodzą z banku.

Odpowiednie nagłówki wiadomości e-mail są następujące:

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

Kluczową rzeczą jest to, że kiwibank.co.nz jest legalnym, renomowanym bankiem, z którego pochodzę, i mam rekord SPF, który brzmi:

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"

Po pewnym czytaniu - wydaje się, że Envolope-From jest poprawne, ale „From” zostało sfałszowane. Czy jest jakiś sposób, aby to naprawić / złagodzić bez przerywania „ogólnego” e-maila? Zauważam, że używam Postfix, Spamassassin i policyd (postfix-policyd-spf-perl) - a jeśli to naprawdę tak łatwe do ominięcia, jaki jest sens SPF?

Odpowiedzi:


13

W tym przypadku prawdopodobnie powiedzieli Twojemu serwerowi coś takiego:

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...
.

Rozmowa SMTP (inaczej „koperta”) może mieć inne nagłówki Od / Do niż nagłówki wiadomości e-mail. SPF nie sprawdza nagłówka, jednak zawsze jest to nagłówek wyświetlany użytkownikowi końcowemu! Tak, SMTP , że złamane. Tak, SPF jest , że złamana.

Będziesz najlepiej obsługiwany, sprawdzając DMARC zamiast tylko SPF. DMARC domyślnie sprawdza SPF, ale sprawdza także wyrównanie nagłówka From z SMTP MAIL FROM (domeny muszą się zgadzać - ignoruje część nazwy użytkownika). Jako bonus można uzyskać wsparcie DKIM, które jest bardzo przydatnym dodatkiem do SPF.

DMARC zależałby od rekordu DNS TXT ustawionego na _dmarc.kiwibank.co.nz. ale obecnie ich nie ma. Według obecnego stanu przepisów internetowych oznacza to właściciela kiwibank.co.nz. wcale nie dba o ochronę przed takimi fałszywkami. Ale w niektórych implementacjach możesz wymusić DMARC dla wszystkich przychodzących wiadomości e-mail.


SPF nie jest zepsuty. Sama poczta jest tutaj zepsuta. Koperta do! = Nagłówek ma dobre powody. Koperta między domenami z! = Nagłówek z nie ma dobrych powodów.
joshudson

1
@joshudson tak to robi. Na przykład, jeśli skonfiguruję .forwardplik (lub inne przekazywanie wiadomości e-mail) do przekazywania z jednego z moich kont na inne, sensowne jest zachowanie, kto jest wiadomością (z nagłówka) i wyświetlanie go jako tego, kto pochodzi z klient poczty e-mail itp. Jednak wszelkie odbicia generowane przez to przekazywanie (nadawca koperty) powinny trafiać do mnie, a nie do osoby, która pierwotnie wysłała wiadomość. To samo dotyczy list mailingowych.
derobert

1
@derobert Listy mailingowe są na marginesie. Klienci poczty nie ostrzegają użytkowników przed oczywistą fałszywką - to ogromny problem i żadne .forwardużycie tego nie uzasadnia.
kubańczyk

To jest po prostu niesamowite.
g33kz0r

2

Po pewnym czytaniu - wydaje się, że Envolope-From jest poprawne, ale „From” zostało sfałszowane. Czy jest jakiś sposób, aby to naprawić / złagodzić bez przerywania „ogólnego” e-maila?

Weryfikacja Fromnagłówka spowoduje uszkodzenie list adresowych:

  1. foo @ yourbank wysyła wiadomość na cat-picture-sharing-list @ bar.

  2. Lista mailingowa odbierze pocztę,

    • zamień na Envelope-Fromcoś podobnego do cat-picture-sharing-list-bounce @ bar,
    • ewentualnie zmodyfikuj nagłówek Odpowiedz na i
    • ponownie wyślij wiadomość e-mail do wszystkich odbiorców (np. Ciebie).

Teraz twój serwer pocztowy otrzymuje wiadomość

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

wysłane z serwerów pocztowych baru.

Zauważam, że używam Postfix, Spamassassin i policyd (postfix-policyd-spf-perl) - a jeśli to naprawdę tak łatwe do ominięcia, jaki jest sens SPF?

  1. Wielu spamerów nie zadaje sobie trudu, aby wysłać „prawidłową” kopertę od.
  2. Twój bank nie otrzyma (większość) rozproszenia wstecznego dla tej wiadomości spamowej, ponieważ raporty NDR są (lub powinny być) wysłane na adres Envelope-From.
  3. Punktacja oparta na Envelope-From staje się bardziej niezawodna. Jeśli ty (lub jakiś zaufany dostawca oceniania) przypisujesz wszystkie wiadomości e-mail z Envelope-From = ... @bank bardzo negatywny wynik spamu, spamerzy nie mogą tego nadużywać.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.