Fałszowanie nagłówków email

[xorg 693]

Hey,

 

czy fałszowanie nagłówków email (najczęściej replyto oraz from) jest w pełni legalne, w szczególności na współdzielonym hostingu ? Żaden hosting nie ma wzmianki w regulaminie na ten temat.

[is_wm 287]

From na pewno może być traktowane jako phishing, szczególnie jak podasz że otrzymujesz list np. od google Można za to wejść na RBL.

[m.p 0]

Współdzielony hosting ma niestety pewną wadę - serwer wysyłający pocztę w większości przypadków ma ten adres adres IP dla wielu kont i SPF nic tutaj nie pomoże...

[kafi 2425]

Czy ja wiem, czy nie ma żaden... co niektóre mają w regulaminie (albo załącznikach do regulaminu).

Poza tym na porządnych, przy próbie wysłania wiadomości via SMTP z nie swojego adresu dostaniesz ładny error 5xx Not Owned.

[xorg 693]

Po prostu ktoś wysyła spam fałszując nagłówki na moją domenę, a odpowiedź od hekko "radź sobie sam". To co, mam ich błagać na kolanach aby nie wysyłali takich listów, czy co ? Bo ja nie rozumiem tego.

[beliq 442]

Po prostu ktoś wysyła spam fałszując nagłówki na moją domenę, a odpowiedź od hekko "radź sobie sam". To co, mam ich błagać na kolanach aby nie wysyłali takich listów, czy co ? Bo ja nie rozumiem tego.

Ja bym proponował zacząć od bardzo dokładnego opisu problemu.

Z serwerami mam doczynienia na codzień i nauczyłem sie już trochę domyślać meritum

na podstawie praktycznie losowo zestawionych słów, nie mniej jednak Twój bełkot nic mi nie mówi.

Piszę to również jako moderator. Wyraź się proszę poprawnie, albo wątek poleci do kosza.

[xorg 693]

Więc na polskie.

 

Ktoś wysyła masowy mailing podając w nagłówkach adres mojej domeny, przez co mam wiele problemów przez to (każdy szary user niezbyt obeznany jest w tych sprawach aby sprawdzić czy aby na pewno z dobrej domeny przyszedł mail). Hosting z którego został wysłany mailing (hekko) napisał mi iż mam radzić sobie sam.

 

A samo sedno tematu, czy takim czymś nie powinien zająć się usługodawca, zamiast odsyłać mnie ?

[matt 0]

Poprawcie mnie jeśli się nie mam racji... from i replyto można dowolnie ustawić niezależnie od serwera, dopiero w dokładnym nagłówku wiadomości można znaleźć dokładny adres nadawcy.

[xorg 693]

Poprawcie mnie jeśli się nie mam racji... from i replyto można dowolnie ustawić niezależnie od serwera, dopiero w dokładnym nagłówku wiadomości można znaleźć dokładny adres nadawcy.

Dokładnie tak jest. I właśnie to wykorzystują.

[d.v 1409]

mailto:abuse@usługodawca.z.którego.korzysta.podszywający.się.pod.twój.adres

[kafi 2425]

Dokładnie tak jest. I właśnie to wykorzystują.

Część *porządnych* providerów filtruje na swoim MTA wysyłki klienckie, że po autoryzacji i próbie przedstawienia się FROM nieswójadres raczy nas miłym komunikatem 5xx Not Owned.

Niestety, każdy z testowanych przeze mnie directadminowych hostów oferuje praktycznie nieograniczony relay ze wszystkich adresów e-mail obsługiwanych przez serwer. Kiedyś nawet próbowałem napisać do tego łatkę, ale ze względu na to, że developerzy czy to Exima, czy to DA nie widzą w tym zachowaniu nic niewłaściwego, to po prostu zaprzestałem kombinacji. W Postfixie natomiast nie jest to żadnym problemem

 

Natomiast wysyłki z anonimowych SMTP nie filtrujących nadawców odbijane są przez większość szanowanych firm na poziomie SPF.

[m.p 0]

mailto:abuse@usługodawca.z.którego.korzysta.podszywający.się.pod.twój.adres

 

Po prostu ktoś wysyła spam fałszując nagłówki na moją domenę, a odpowiedź od hekko "radź sobie sam". To co, mam ich błagać na kolanach aby nie wysyłali takich listów, czy co ? Bo ja nie rozumiem tego.

[d.v 1409]

Usługodawca (w tym przypadku Hekko) ma zasmarkany obowiązek się tym zająć, szczególnie, jeśli prócz podszywania się jest jeszcze spamowanie. Na ich miejscu nie zastanawiałbym się ani sekundy, po sprawdzeniu czy rzeczywiście takie coś miało miejsce natychmiastowa blokada konta, z którego idzie tego typu wysyłka. Widać chcą xorgowi zrobić na złość...

[is_wm 287]

A mozesz pokazac pelny naglowek?

[p 3]

Poprawcie mnie jeśli się nie mam racji... from i replyto można dowolnie ustawić niezależnie od serwera, dopiero w dokładnym nagłówku wiadomości można znaleźć dokładny adres nadawcy.

Dokładnie tak jest. I właśnie to wykorzystują.

Co prawda Fiercio już to napisał, ale dla uzupełnienia podam wycinek z logów porządnego serwera

In: MAIL FROM: <istniejacy.adres@dot.com>

Out: 250 2.1.0 Ok

In: RCPT TO: <xxx@xxx.com>

Out: 553 5.7.1 <istniejacy.adres@dot.com>: Sender address rejected: not owned by user authenticated.user@dot.com

[malu 460]

Hi!

 

Ja zabrałem się swego czasu do napisania "swego rodzaju łatki" do directadminowych hostów.

Dokładnie to miałem zamiar dopisać tu i ówdzie coś do exim.pl - ale niestety porzuciłem to i tak to się odwleka do dziś.

W sumie ten temat to może dobra okazja, żeby do tego wrócić.

[beliq 442]

No niestety... Jest duży problem z wdrożeniem sender access verification w tandemie DA+Exim,

bo w zdecydowanej większości firm 127.0.0.1 musi być relay hostem,

a co sprawia, że przez skrypt wysłać wszystko...

Dlaczego musi? Bo ludki sobie nie radzą z konfiguracją swoich CMSów jeśli się wymusza autoryzację przesyłek,

a i część popularnego softu webowego nie ma nawet implementacji wysyłki maili w ten sposób.

 

Z drugiej strony zawsze chciałem coś takiego zrobić, bo to faktycznie źle, że taka możliwość istnieje.

Cóż, za każdym razem inne sprawy brały górę ,

a i szczerze mówiąc nie mam pomysłu jak biorąc pod uwagę powyższe można to sensownie zrobić.

 

Jeśli ktoś potrafi przygotować zestaw sensowych patchy i wystawić za nie FV,

to chętnie przyjmę via PW na to ofertę...

[xorg 693]

Return-Path: <tonieja9@s2.hekko.net.pl>
Received: by o2.pl (o2.pl mailsystem) with LMTP;
Sun, 13 Sep 2009 16:29:12 +0200
Received: from s2.hekko.net.pl [91.203.133.69]
by mx5.go2.pl with ESMTP id MYEjxM;
Sun, 13 Sep 2009 16:29:12 +0200
Received: from tonieja9 by s2.hekko.net.pl with local (Exim 4.67)
(envelope-from <tonieja9@s2.hekko.net.pl>)
id 1Mmq1P-00033Z-NZ; Sun, 13 Sep 2009 16:25:43 +0200
To: zigo5@wp.pl
Subject: Sie? Serwerów BingBang.eu Steam i NS
X-PHP-Script: bbgaming.pl/spam/admin/admin_mass_email.php for 85.193.231.60
Reply-to: seba@cs-puchatek.pl
From: cspuchatek@cs-puchatek.pl <cspuchatek@cs-puchatek.pl>
Message-ID: <8b04cccd247661be8aa83acf97c246b6@bbgaming.pl>
MIME-Version: 1.0
Content-type: text/html; charset=iso-8859-2
Content-transfer-encoding: 8bit
Date: Sun, 13 Sep 2009 16:25:43 +0200
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: PHP
X-MimeOLE: Produced By phpBB2
X-AntiAbuse: Board servername - bbgaming.pl
X-AntiAbuse: User_id - 2
X-AntiAbuse: Username - jaja
X-AntiAbuse: User IP - 85.193.231.60
Sender:  <tonieja9@s2.hekko.net.pl>
X-O2-Trust: 2, 75

Oto cały nagłówek =]

 

PS. Chyba hekko czyta to forum bo mają teraz zablokowane konto (o ile to nie jest blokada z innego powodu). Podsumowując, jest to kolejny dowód że to forum jest lepsze od supportu.

[kafi 2425]

Może tak zamiast lamentować i lamentować, to pewne kroki można ze swojej strony podjąć... np. wrzucenie do strefy DNS rekordu SPF.

 

@bell - mi by wystarczyła na początek weryfikacja sender address na poziomie AUTH-SMTP, żeby pani Jadzia będąca sprzątaczką nie mogła sobie wpisać adresu FROM szef@.

A jak ludzi zmusić... wyciąć funkcję mail

[megi 358]

Co prawda Fiercio już to napisał, ale dla uzupełnienia podam wycinek z logów porządnego serwera

 

553 5.7.1 <istniejacy.adres@dot.com>: Sender address rejected: not owned by user authenticated.user@dot.com

 

Po tym jak xorg napisał, że chodzi o from i replay-to oraz o nieobeznanych userach, którzy nie potrafią sprawdzić skąd naprawdę przyszedł mail, łatwo się domyślić, że nie chodzi o envelope sender, który jest później widoczny jako return-path a nagłówki idące jako treść maila Te można ustawić dowolnie. Poza tym ograniczenia nałożone na smtp nie pomogą jeżeli maile wysyłane są lokalnie przez sendmaila.

 

Return-Path: <tonieja9@s2.hekko.net.pl>

(...)

Received: from tonieja9 by s2.hekko.net.pl with local (Exim 4.67)

(envelope-from <tonieja9@s2.hekko.net.pl>)

id 1Mmq1P-00033Z-NZ; Sun, 13 Sep 2009 16:25:43 +0200

Reply-to: seba@cs-puchatek.pl

From: cspuchatek@cs-puchatek.pl <cspuchatek@cs-puchatek.pl>

Może tak zamiast lamentować i lamentować, to pewne kroki można ze swojej strony podjąć... np. wrzucenie do strefy DNS rekordu SPF.

Co to da w tej sytuacji?

[kafi 2425]

Co to da w tej sytuacji?

W tej konkretnej akurat może niewiele, ale część bardziej rozwiniętych MTA analizuje całą treść wiadomości, w tym i nagłówek FROM, oraz to, że envelope-sender != FROM.

[megi 358]

W tej konkretnej akurat może niewiele, ale część bardziej rozwiniętych MTA analizuje całą treść wiadomości, w tym i nagłówek FROM

 

Hmm, MTA z pudełka tak nie robią, chyba, że podasz jakiś przykład, to jestem gotowa zmienić zdanie. Jakieś dodatkowe filtry, amavis i te okolice to możliwe.

 

oraz to, że envelope-sender != FROM.

 

Naprawdę? :>

Envelope sender to jest nadawca podawany na etapie sesji SMTP czyli to o czym pisaliście z p (MAIL FROM: <cośtam@cośtam>) i to jest widoczne jako return-path w pełnych nagłówkach maila, xorg pisał o polu from widocznym standardowo w nagłówkach w programie pocztowym czyli o nagłówku, który z perspektywy smtp jest treścią maila. Tak, zgadza się - to nie jest to samo. Właśnie o tym pisałam. Blokowanie możliwości uwierzytelnienia się jednym adresem a wysyłanie z innego tutaj nie pomoże, tak samo jak ustawienie SPFa. Nie wieszałabym psów na Hekko za konfigurację MTA

[kafi 2425]

Może jeszcze raz, troszkę inaczej napiszę, o co mi chodziło.

Niektóre MTA (zgadza się - nie pudełkowe, ale ich modyfikacje/własne rozwiązania) analizują treść CAŁEJ wiadomości i sprawdzają także to, czy MAIL FROM jest tym samym, co nagłówek FROM w dalszej części wiadomości, a jak nie, to maila albo odrzucą - odeślą zamiast komunikatu queued jakiś inny, albo też zaakceptują, ale mail trafi od razu do spamu.

[p 3]

Po tym jak xorg napisał, że chodzi o from i replay-to oraz o nieobeznanych userach, którzy nie potrafią sprawdzić skąd naprawdę przyszedł mail, łatwo się domyślić, że nie chodzi o envelope sender, który jest później widoczny jako return-path a nagłówki idące jako treść maila Te można ustawić dowolnie. Poza tym ograniczenia nałożone na smtp nie pomogą jeżeli maile wysyłane są lokalnie przez sendmaila.

Wiedziałem, że się ktoś doczepi Z jednej strony masz rację, z drugiej strony patrz niżej

 

W tej konkretnej akurat może niewiele, ale część bardziej rozwiniętych MTA analizuje całą treść wiadomości, w tym i nagłówek FROM, oraz to, że envelope-sender != FROM.

Może jeszcze raz, troszkę inaczej napiszę, o co mi chodziło.

Niektóre MTA (zgadza się - nie pudełkowe, ale ich modyfikacje/własne rozwiązania) analizują treść CAŁEJ wiadomości i sprawdzają także to, czy MAIL FROM jest tym samym, co nagłówek FROM w dalszej części wiadomości, a jak nie, to maila albo odrzucą - odeślą zamiast komunikatu queued jakiś inny, albo też zaakceptują, ale mail trafi od razu do spamu.

Tyle tylko, że "From" != envelope-sender jest jak najbardziej dozwolone i w ogólności na tej podstawie nie należy blokować maili...

 

Poza tym na ile sensowne jest takie filtrowanie? Załóżmy maila z takimi nagłówkami:

Return-Path: <tonieja9@s2.hekko.net.pl>

From: "cspuchatek@cs-puchatek.pl" <tonieja9@s2.hekko.net.pl>

 

Z punktu widzenia większośći (wszystkich?) filtrów będzie wyglądało to tak:

mfrom: tonieja9@s2.hekko.net.pl (czyli OK)

pra: tonieja9@s2.hekko.net.pl (czyli OK)

 

Natomiast MUA i tak wyświetli display-name, czyli: cspuchatek@cs-puchatek.pl, a filtrowanie po display-name to już chyba lekka przesada... Chociaż oczywiście wszystko i tak zależy od widzi-mi-się postmastera

[kafi 2425]

Tyle tylko, że "From" != envelope-sender jest jak najbardziej dozwolone i w ogólności na tej podstawie nie należy blokować maili...

Blokować może nie... ale do worka ze spamem można zaklasyfikować

Jedyny, znany mi przypadek to wysyłanie poczty "on behalf of" - ale wtedy doklejany jest też nagłówek SENDER z adresem oryginalnego nadawcy.

 

Poza tym, to nie oszukujmy się - wyfiltrować cwaniaków podszywających się jest bardzo trudno, i czasami nawet bezsensownie.

Ale u licha powinna IMO być zaimplementowana chociażby podstawowa blokada przed użyciem normalnego programu pocztowego, w którym ktoś przypadkowo w konfiguracji wpisze nie swój adres pocztowy.