Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Sposob na spam i wirusy?

10 views
Skip to first unread message

Marek Wodzinski

unread,
Feb 4, 2004, 7:54:56 AM2/4/04
to
Witam.

Od wczoraj toczy sie na grupie isp-tech dyskusja, ktora zaczela sie od
pomyslu ciekawego filtru do postfixa Sergiusza Rozanskiego:
http://www.comm.pl/~serek/mxfilter/

Od narzedzia przeszlo na idee i chcialbym sie z wami podzielic pomyslem,
ktory jest rozszerzeniem tego co zaproponowal Sergiusz.

W skrocie:
Chodzi o to, zeby przy przyjeciu poczty sprawdzac czy adres we FROM w
kopercie jest zgodny z odpowiednim serwerem smtp, ktory powinien wyslac
takiego maila. W sumie jest to jakby proba rozszerzenia tego co Onet
nazywa antyoszustem do skali globalnej. Dzialanie sprowadza sie do
odpytania dns-u wlasciciela domeny we FROM o odpowiednie rekordy A i
sprawdzenie tego z ip z ktorego przychodzi polaczenie.

Krotki opis od strony technicznej (w zasadzie propozycje i mozliwe
rozwiazania):
- provider obslugujacy domene robi poddomene np. relay.jakasdomena.pl
(relay, smtp-out, whatever byle jedna i ustalona globalnie)
- maly/leniwy provider robi wpis:
*.relay.jakasdomena.pl IN A 1.2.3.4
- jezeli klient malego providera (j...@jakasdomena.pl) ma swoj serwer smtp,
to _dopisujemy_ mu:
jas.jakasdomena.pl.relay.jakasdomena.pl IN A 1.2.3.4
jas.jakasdomena.pl.relay.jakasdomena.pl IN A ip.jego.sdi.bla
- bardziej paranoiczny maly provider robi wpisy dla kazdego maila typu:
jas.jakasdomena.pl.relay.jakasdomena.pl IN A 1.2.3.4
- jw., ale wiekszy provider robi to skryptem:-)
- bardzo duzy provider obslugujacy wiele domen robi wpis dla kazdej
domeny:
relay.jakasdomena.pl IN NS megadns.jakisprovider.pl
jezeli jest duzy, to juz sobie poradzi z modyfikacja/konfiguracja demona
dns na megadns.jakisprovider.pl:-)

Zalety:
- sprawdzenie czy przeszlo przez odpowiedni serwer
- wyciecie falszywych adresow o ile nie konfigurujemy rekordu z *
- w ekstremalnym przypadku mozna nawet zdejmowac/zmieniac na 127. w jakis
czas po wypchnieciu maila, zeby nie mozna bylo skorzystac z 'sesji'
prawdziwego wysylajacego.
- banalnie prosta podstawowa konfiguracja po stronie providera nadawcy,
jednoczesnie dajaca mozliwosci rozwoju
- dosyc prosta i elastyczna obsluga od strony mta
- dosyc proste dodawanie wyjatkow dla poszczegolnych userow providera
- wszystko odbywa sie na poczatku sesji smtp przed przyjeciem danych
- z technicznego punktu widzenia wprowadzenie takiego
podstawowego 'podpisania' sie serwerow smtp dla wiekszosci z providerow
jest tylko kwestia pojedynczyc dni o ile nie minut:-)

Wady:
- trzeba sie umowic jak ma sie nazywac ta poddomena :-)
- trzeba to zrobic

Jak bede mial wiecej czasu to chetnie postaram sie jakos rozszerzyc opis.
Uwagi jak najbardziej mile widziane (najlepiej na grupe) - bo moze jednak
jest jakis backdoor w tym rozumowaniu?


pozdrawiam

majek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg

PiK

unread,
Feb 4, 2004, 1:04:05 PM2/4/04
to

Uzytkownik "Marek Wodzinski" <ma...@ODSPAMIACZ.mamy.to> napisal w wiadomosci
news:Pine.LNX.4.58.04...@toster.pilczyce.net...

> W skrocie:
> Chodzi o to, zeby przy przyjeciu poczty sprawdzac czy adres we FROM w
> kopercie jest zgodny z odpowiednim serwerem smtp, ktory powinien wyslac
> takiego maila

Taki projekt juz jest - na etapie zatwierdzania RFC. A dziur w tym
rozumowaniu jest kilka i trwa dyskusja jak to rozwiazac najlepiej. Szczególy
na stronie

http://www.pan-am.ca/dmp/

PiK

PS. Lukaszu, pamietam ze obiecalem o tym napisac. Jeszcze troche, moze bede
mógl napisac cos wiecej.


Marek Wodzinski

unread,
Feb 4, 2004, 1:30:34 PM2/4/04
to
On Wed, 4 Feb 2004, PiK wrote:

>
> Uzytkownik "Marek Wodzinski" <ma...@ODSPAMIACZ.mamy.to> napisal w wiadomosci
> news:Pine.LNX.4.58.04...@toster.pilczyce.net...
>
> > W skrocie:
> > Chodzi o to, zeby przy przyjeciu poczty sprawdzac czy adres we FROM w
> > kopercie jest zgodny z odpowiednim serwerem smtp, ktory powinien wyslac
> > takiego maila
>
> Taki projekt juz jest - na etapie zatwierdzania RFC. A dziur w tym
> rozumowaniu jest kilka i trwa dyskusja jak to rozwiazac najlepiej. Szczególy
> na stronie
>
> http://www.pan-am.ca/dmp/

hmmm...
1. Nie ma autoryzacji na poziomie loginu, a tylko po calej domenie
2. Pozwala na uzywanie wildcardow jezeli chodzi o ip, a to oznacza, ze
kazdy spamer ze swoja domena lub domena providera 'ofiary' moze to obejsc
bez zadnego problemu.

Bronek Kozicki

unread,
Feb 4, 2004, 2:16:07 PM2/4/04
to
On Wed, 4 Feb 2004 19:30:34 +0100, Marek Wodzinski wrote:
> 1. Nie ma autoryzacji na poziomie loginu, a tylko po calej domenie
odpowiedzialność administratora serwera , a nie poszczególnych userów.
Jak wyobrażasz sobie wykorzystanie autoryzacji na poziomie loginu?

> 2. Pozwala na uzywanie wildcardow jezeli chodzi o ip, a to oznacza, ze
> kazdy spamer ze swoja domena lub domena providera 'ofiary' moze to obejsc
> bez zadnego problemu.

wtedy wycinasz domenę. Dzieki zastosowaniu DMP masz pewność, że poczta
przychodzi z tych IP, które są desygnowane przez właściciela domeny, w
związku z tym *możesz* pociągać do odpowiedzialności na podstawie nazwy
domeny

inaczej rzecz ujmując: samo DMP problemu nie załatwi, ale pozwoli na
wykorzystanie RBL lub whitelisting dla domen w sposób analogiczny jak
działa obecnie RBL dla IP.


B.

Dariusz Sznajder

unread,
Feb 4, 2004, 2:22:56 PM2/4/04
to
W artykule <Pine.LNX.4.58.04...@toster.pilczyce.net>
Marek Wodzinski napisał(a):

> 1. Nie ma autoryzacji na poziomie loginu, a tylko po calej domenie
A co to ma być?

> 2. Pozwala na uzywanie wildcardow jezeli chodzi o ip, a to oznacza, ze
> kazdy spamer ze swoja domena lub domena providera 'ofiary' moze to obejsc
> bez zadnego problemu.

A gdzie w Twojej propozycji jest zabezpieczenie przed tym?

--
Dariusz Sznajder
DSZ1-RIPE

Lukasz Kozicki

unread,
Feb 4, 2004, 6:13:43 PM2/4/04
to
Marek Wodzinski wrote:

> pomyslu ciekawego filtru do postfixa Sergiusza Rozanskiego:
> http://www.comm.pl/~serek/mxfilter/

Jako lekturę uzupełniającą - by nie wyważac otwartych drzwi,
proponuję jeszcze, poza wskazanym już przez PiK-a DMP :

TEOS http://eprivacygroup.net/teos/
AMTP http://amtp.bw.org/
RMX http://www.mikerubel.org/computers/rmx_records/
SPF http://spf.pobox.com/

Pozdrawiam,
--
Łukasz Kozicki

Marek Wodzinski

unread,
Feb 5, 2004, 3:01:29 AM2/5/04
to
On Wed, 4 Feb 2004, Bronek Kozicki wrote:

> On Wed, 4 Feb 2004 19:30:34 +0100, Marek Wodzinski wrote:
> > 1. Nie ma autoryzacji na poziomie loginu, a tylko po calej domenie
> odpowiedzialność administratora serwera , a nie poszczególnych userów.
> Jak wyobrażasz sobie wykorzystanie autoryzacji na poziomie loginu?

Chodzi o to, ze jak przychodzi do Ciebie mail z powiedzmy
j...@jakasdomena.pl, to nie pytasz sie tylko czy list z jakasdomena.pl moze
przyjsc z tego relaya, ale czy list z j...@jakasdomena.pl moze z tamtad
przyjsc.
Daje to _mozliwosc_ zrobienia providerowi trzymajacemu te skrzynki
rekordow w dns dla kazdej skrzynki osobno, wlacznie z ustawieniem rekordu
typu 127.x.x.x dla nieistniejacych skrzynek. Wtedy Ty odbierajac taka
poczte mozesz z czystym sumieniem wywalic do kosza maila z
jo...@jakasdomena.pl, bo tamten provider powiedzial Ci, ze takiej skrzynki
nie ma.
Wiecej: dysponujac dobrym dynamicznym dns-em i zmodyfikowanym mta provider
moze ustawiac odpowiedni rekord w dns-ie tylko na czas trwania wysylania
danego maila.
Zauwaz, ze wiele mta w tej chwili nawet jak ma ustawiona autoryzacje czy
pop-before-smtp, to mimo, ze zautoryzowal sie j...@jakasdomena.pl, to
pozwalaja na wysylanie maili od jo...@jakasdomena.pl
Jezeli jest kontrola nad cala informacja jaka podaje klient, to jest to
zawsze lepiej niz sprawdzanie tylko domeny.
A jak provider chce szybciutko sobie skonfigurowac, to moze wtawic po
prosty * w dns-ie w miejscu loginow.
Daje to tez mozliwosc dopisania dla konkretnych e-maili innych zestawow
relayow, jezeli klient z mailem j...@jakasdomena.pl korzysta np. ze swojego
serwera smtp na sdi.

Zauwaz, ze RMX tez ma taka mozliwosc, ale uzywa z
zalozenia niestandardowych rekordow dns i oznacza to, ze bez patchowania
dns-ow nie jestes w stanie go porzadnie zastosowac.
Poza tym rowniez pozwala na wildcardy.

> > 2. Pozwala na uzywanie wildcardow jezeli chodzi o ip, a to oznacza, ze
> > kazdy spamer ze swoja domena lub domena providera 'ofiary' moze to obejsc
> > bez zadnego problemu.
> wtedy wycinasz domenę. Dzieki zastosowaniu DMP masz pewność, że poczta
> przychodzi z tych IP, które są desygnowane przez właściciela domeny, w
> związku z tym *możesz* pociągać do odpowiedzialności na podstawie nazwy
> domeny

Jakie konsekwencje wyciagasz dla domen rejestrowanych na jeden wysyp
spamu idacy przez open-proxy/zombie? DMP pozwala na wpisanie * w rekord
opkreslajacy zakres adresow nadawcy, wiec spamera NIC nie kosztuje zrobic
sobie rekord obejmujacy caly internet.
Jezeli musisz podac bez mozliwosci wildcardow odpowiednie relaye, to
przynajmniej spamerzy z open-proxy tego tak latwo nie przeskocza, a
reszte bedzie mozna wyblokowac:-).

Marek Wodzinski

unread,
Feb 5, 2004, 3:06:29 AM2/5/04
to
On Wed, 4 Feb 2004, Dariusz Sznajder wrote:

> W artykule <Pine.LNX.4.58.04...@toster.pilczyce.net>
> Marek Wodzinski napisał(a):
> > 1. Nie ma autoryzacji na poziomie loginu, a tylko po calej domenie
> A co to ma być?

Odpowiedz jest w <Pine.LNX.4.58.04...@toster.pilczyce.net>

> > 2. Pozwala na uzywanie wildcardow jezeli chodzi o ip, a to oznacza, ze
> > kazdy spamer ze swoja domena lub domena providera 'ofiary' moze to obejsc
> > bez zadnego problemu.
> A gdzie w Twojej propozycji jest zabezpieczenie przed tym?

Po prostu nie wpiszesz do dns-a calego internetu...
Jezeli nie ma mozliwosci stosowania wildcardow, to tej mozliwosci nie
naduzyjesz. RMX, DMP czy SPF nie sa zadna przeszkoda dla spamera z
kolejna wlasna domena do czasu jej usuniecia. Po usunieciu i tak wiekszosc
mta juz tego nie przyjmie...

Marek Wodzinski

unread,
Feb 5, 2004, 3:40:14 AM2/5/04
to
On Thu, 5 Feb 2004, Lukasz Kozicki wrote:

> Marek Wodzinski wrote:
>
> > pomyslu ciekawego filtru do postfixa Sergiusza Rozanskiego:
> > http://www.comm.pl/~serek/mxfilter/
>
> Jako lekturę uzupełniającą - by nie wyważac otwartych drzwi,
> proponuję jeszcze, poza wskazanym już przez PiK-a DMP :
>
> TEOS http://eprivacygroup.net/teos/

Domena nie istnieje, ale kopia google mowi, o jakis trustach itp...
Jezeli jakas inicjatywa ma jeszcze zalezec od podmiotu trzeciego, to
napewno szybko sie nie rozwinie. To juz lepiej wymyslic nowy protokol:-)

> AMTP http://amtp.bw.org/

Dodatkowy protokol? Moze kiedys....

> RMX http://www.mikerubel.org/computers/rmx_records/

Swoje wynalazki w dns-ie i wildcardy - do obejscia przez spamerow z wlasna
domena.

> SPF http://spf.pobox.com/

jw., ale bez wynalazkow:-)

Dodatkowo wszystkie staraja sie byc elastyczne poprzez skomplikowanie.

Proponujac pewne rozwiazanie staralem sie, zeby bylo proste i bardzo
szybkie do wprowadzenia w zycie.
Od strony providera sprowadza sie to do dopisania jednej poddomeny do
kazdej obslugiwanej - jezeli provider chce skorzystac z dodatkowych
mozliwosci, to juz sobie cos wyrzezbi.
Od strony odbiorcy w zasadzie zachodzi dosyc proste sprawdzenie bez
parsowania rekordow tekstowych lub jakis wlasnych.
No i mniej mozliwosci popelnienia bledu przy konfiguracji.

Dariusz Sznajder

unread,
Feb 5, 2004, 4:20:49 AM2/5/04
to
W artykule <Pine.LNX.4.58.04...@toster.pilczyce.net>
Marek Wodzinski napisał(a):
> przyjsc z tego relaya, ale czy list z j...@jakasdomena.pl moze z tamtad
> przyjsc.
[...]

> typu 127.x.x.x dla nieistniejacych skrzynek. Wtedy Ty odbierajac taka
Zdajesz sobie sprawe, że nieistniejących skrzynek jest ehm... dużo?

[...]


> poczte mozesz z czystym sumieniem wywalic do kosza maila z
> jo...@jakasdomena.pl, bo tamten provider powiedzial Ci, ze takiej skrzynki
> nie ma.

To ma sens, ale nie dla takich zastosowań.
Raczej dla zastosowań typu: generalnie 95% naszych użytkowników wysyła
tylko od nas; ale jozek@ i franek@ są handlowcami i wysyłają skąd im
się uda, w tym takich, gdzie bezpośrednio nie mogą się połączyć, a
jasiek@ wysyła też z domu; akceptujcie jozka, franka i jaśka z zewnątrz.

> Zauwaz, ze wiele mta w tej chwili nawet jak ma ustawiona autoryzacje czy
> pop-before-smtp, to mimo, ze zautoryzowal sie j...@jakasdomena.pl, to
> pozwalaja na wysylanie maili od jo...@jakasdomena.pl

Nie widzę związku?

> Jezeli musisz podac bez mozliwosci wildcardow odpowiednie relaye, to
> przynajmniej spamerzy z open-proxy tego tak latwo nie przeskocza, a
> reszte bedzie mozna wyblokowac:-).

Dlaczego nie przeskoczą?
W najgorszym razie wystarczy sobie zmodyfikować serwer DNSu.
Umówmy się - metody oparte na wiarygodności DNSu _nigdy_ nie będą
odporne na brak tej wiarygodności.

SPF, DMP etc. nie mają zabezpieczać przed spamem, czy wirusami.
To jest skutek uboczny.
Mają zabezpieczać przed fałszowaniem FROM w kopercie.
Tylko tyle.

--
Dariusz Sznajder
DSZ1-RIPE

Dariusz Sznajder

unread,
Feb 5, 2004, 4:38:32 AM2/5/04
to
W artykule <Pine.LNX.4.58.04...@toster.pilczyce.net>
Marek Wodzinski napisał(a):
> Dodatkowo wszystkie staraja sie byc elastyczne poprzez skomplikowanie.
Elastyczność to zaleta - nie wada.
Wpisywanie po kilka tysięcy adresów przez dużych (np. taki AOL),
a wpisanie 1 lini to jednak jest pewna różnica.

> kazdej obslugiwanej - jezeli provider chce skorzystac z dodatkowych
> mozliwosci, to juz sobie cos wyrzezbi.

Tylko, widzisz - chodzi właśnie o to, żeby wszyscy rzeźbili w tym samym.
Jesli każdy będzie rzeźbil po swojemu, to nic z tego ni wyjdzie.
I dlatego dąży się do powstania jakiegoś RFC.

--
Dariusz Sznajder
DSZ1-RIPE

Marek Wodzinski

unread,
Feb 5, 2004, 5:02:40 AM2/5/04
to
On Thu, 5 Feb 2004, Dariusz Sznajder wrote:

> W artykule <Pine.LNX.4.58.04...@toster.pilczyce.net>
> Marek Wodzinski napisał(a):
> > przyjsc z tego relaya, ale czy list z j...@jakasdomena.pl moze z tamtad
> > przyjsc.
> [...]
> > typu 127.x.x.x dla nieistniejacych skrzynek. Wtedy Ty odbierajac taka
> Zdajesz sobie sprawe, że nieistniejących skrzynek jest ehm... dużo?

domena relay.jakasdomena.pl:
jas IN A 1.2.3.4
malosia IN A 1.2.3.4
* IN A 127.x.x.x
Jak widac, zaden problem (w bindzie dziala).
Jezeli ktos nie chce pokazywac na zewnatrz jakie ma skrzynki, to moze
wlasnie zastosowac w calej domenie tylko:
* IN A 1.2.3.4
Poza tym to jest _mozliwosc_ wykorzystania tego rozwiazania. Czy ta
mozliwosc provider wykorzysta, to juz jego decyzja. Moze tego nie zrobic
chocby ze wzgledu na chec nieujawniania nazw skrzynek dla brute-force
skanow dns-owych.

> [...]
> > poczte mozesz z czystym sumieniem wywalic do kosza maila z
> > jo...@jakasdomena.pl, bo tamten provider powiedzial Ci, ze takiej skrzynki
> > nie ma.
> To ma sens, ale nie dla takich zastosowań.
> Raczej dla zastosowań typu: generalnie 95% naszych użytkowników wysyła
> tylko od nas; ale jozek@ i franek@ są handlowcami i wysyłają skąd im
> się uda, w tym takich, gdzie bezpośrednio nie mogą się połączyć, a
> jasiek@ wysyła też z domu; akceptujcie jozka, franka i jaśka z zewnątrz.

Wysylaja przez obce _smtp_? Zawsze rozne? I kto im na to pozwala?

> > Zauwaz, ze wiele mta w tej chwili nawet jak ma ustawiona autoryzacje czy
> > pop-before-smtp, to mimo, ze zautoryzowal sie j...@jakasdomena.pl, to
> > pozwalaja na wysylanie maili od jo...@jakasdomena.pl
> Nie widzę związku?

Jezeli przuchodzi do Ciebie mail z j...@jakasdomena.pl, to dostajesz
odpowiedz typu 1.2.3.4 - wtedy sprawdzasz ip i wpuszczasz lub nie, lub
dajesz szanse dalszym regulkom.
Jezeli przychodzi mail od jo...@jakasdomena.pl i na pytanie o smtp
dostajesz odpowiedz 127.x.x.x co oznacza brak takiej skrzynki/aliasu u
providera, to wpuszczasz? dajesz szanse innym filtrom czy od razu wywalasz
smiecia?
A zwiazek jest taki, ze user/wirus przynajmniej nie posle dalej ze
zmyslonego loginu przez wlasciwy serwer smtp. Ale to i tak bylaby
przyszlosc, bo chocby podstawowa implementacja wytepilaby zombie,
open-proxy i wirusy z wlasnym smtp.

> > Jezeli musisz podac bez mozliwosci wildcardow odpowiednie relaye, to
> > przynajmniej spamerzy z open-proxy tego tak latwo nie przeskocza, a
> > reszte bedzie mozna wyblokowac:-).
> Dlaczego nie przeskoczą?

Napisalem tylko, ze to bedzie o wiele trudniejsze niz wpisanie calego
internetu jedna *.
Systemy uwierzytelniania nadawcy dajace mozliwosc wildcardow obejmujacych
caly internet sa z zalozenia do kitu - przynajmniej pod katem spamu i
wirusow.

> SPF, DMP etc. nie mają zabezpieczać przed spamem, czy wirusami.
> To jest skutek uboczny.
> Mają zabezpieczać przed fałszowaniem FROM w kopercie.
> Tylko tyle.

Jezeli sprawdzaja tylko domene, to nie wykorzystuja wszystkich (choc i tak
bardzo skapych danych wejsciowych), to jest lekka rozrzutnosc i duzy
margines bledu by-design.

Marek Wodzinski

unread,
Feb 5, 2004, 5:25:58 AM2/5/04
to
On Thu, 5 Feb 2004, Dariusz Sznajder wrote:

> W artykule <Pine.LNX.4.58.04...@toster.pilczyce.net>
> Marek Wodzinski napisał(a):
> > Dodatkowo wszystkie staraja sie byc elastyczne poprzez skomplikowanie.
> Elastyczność to zaleta - nie wada.

Nie kosztem dziur i zlozonosci obliczeniowej (patrz chocby
wiodacy OS).

> Wpisywanie po kilka tysięcy adresów przez dużych (np. taki AOL),
> a wpisanie 1 lini to jednak jest pewna różnica.

Duzy moze zrobic sobie chocby dyndns-a, ktorego smtp wysylajacy
uaktualnialby ipki dla danego adresu, wiec zapytanie zwracaloby tylko
jeden ip lub kilka ostatnich ipkow. Zauwaz, ze dla az tak duzych
providerow nie bedzie problemem zrobienie czegos takiego.
Dla mniejszych - nawet po kilanascie serwerow - nadal nie jest problemem
wpisanie ich wszystkich do dns-u.

> > kazdej obslugiwanej - jezeli provider chce skorzystac z dodatkowych
> > mozliwosci, to juz sobie cos wyrzezbi.
> Tylko, widzisz - chodzi właśnie o to, żeby wszyscy rzeźbili w tym samym.
> Jesli każdy będzie rzeźbil po swojemu, to nic z tego ni wyjdzie.

Wlasnie o to chodzi, ze rzezbic musieliby tylko naprawde bardzo duzi, bo
oni i tak rzezbia - nie mysle, zeby hotmail czy aol nie mieli swojego
dzialu programistow, ktorzy modyfikuja system na biezaco w zaleznosci od
potrzeb, a zamiast tego mieli klik-klik-spinacz, bo i jego ktos musialby
napisac specjalnie dla nich .

> I dlatego dąży się do powstania jakiegoś RFC.

Rzezbienie nie ma nic do RFC - w koncu RFC opisuje Ci tylko metode, a nie
dostarcza zrodel do install>next>next>done.
Co do RFC, to mozna sie i w tym przypadku postarac. Po to jest wlasnie ta
dyskusja, zeby zweryfikowac pomysl, sprawdzic ewentualne poparcie i
sprawdzic czy jest sens to ciagnac dalej. Moze w przepastnych czelusciach
internetu juz to ktos zrobil tylko wlasnie nie wydal stosownego RFC i
pomysl zostal zapomniany u niego na wlasnym podworku?

Bronek Kozicki

unread,
Feb 5, 2004, 5:33:37 AM2/5/04
to
On Thu, 5 Feb 2004 09:01:29 +0100, Marek Wodzinski wrote:

>> On Wed, 4 Feb 2004 19:30:34 +0100, Marek Wodzinski wrote:
>>> 1. Nie ma autoryzacji na poziomie loginu, a tylko po calej domenie
>> odpowiedzialność administratora serwera , a nie poszczególnych userów.
>> Jak wyobrażasz sobie wykorzystanie autoryzacji na poziomie loginu?
>
> Chodzi o to, ze jak przychodzi do Ciebie mail z powiedzmy
> j...@jakasdomena.pl, to nie pytasz sie tylko czy list z jakasdomena.pl moze
> przyjsc z tego relaya, ale czy list z j...@jakasdomena.pl moze z tamtad
> przyjsc.

Rozumiem. Po pierwsze: jaki jest cel takiego systemu? W przypadku DMP
tym celem jest przywrócenie wiarygodności domeny nadawcy. Włączając
również największych providerów darmowych kont (bo z takich adresów
wychodzi spora część światowego spamu). Cel Twojej propozycji jest
niejasny. Nie da się jej zastosować dla ISP obsługującego miliony kont
(w tym darmowych), bo musieliby oni zintegrować system obsługi kont z
DNS. Nierealne, nie masz szans przekonać do tego Yahoo, MSN czy AT&T. To
byłoby nawet bardzo trudne dla ISP o liczbie kont mierzonych w
tysiącach. Zważ, że taki interfejs musiałby być tworzony dla każdej
kombinacji oprogramowania obsługującego DNS i listę kont. Dla średnich
ISP to może nie jest nierealne, ale ciężka sprawa. Twój system w
praktyce da się zastosować do zwiększenia wiarygodności garstki adresów
w domenach posiadających mało kont - a to wyklucza jego powszechność. Co
znaczy, że serwery SMTP nie mogą wymagać jego osbługi od nadawców. W
przypadku DMP koszty wdrożenia są znacznie mniejsze (niewielka ilość
statycznych rekordów w DNS, nawet dla b.dużych ISP), przez co system
może być popularny, przez co serwery SMTP mogą w pewnym momencie w ogóle
odmówić przyjmowania poczty od domen nie obsługujących DMP.

> typu 127.x.x.x dla nieistniejacych skrzynek. Wtedy Ty odbierajac taka
> poczte mozesz z czystym sumieniem wywalic do kosza maila z
> jo...@jakasdomena.pl, bo tamten provider powiedzial Ci, ze takiej skrzynki
> nie ma.

... a spamer zyskuje kolejne narzędzie harvestowania adresów. To już
wygodniej włączyć obsługę VRFY

> Jezeli jest kontrola nad cala informacja jaka podaje klient, to jest to
> zawsze lepiej niz sprawdzanie tylko domeny.

Nie rozumiem dlaczego. Koszt umożliwienia tego sprawdzania wyłącza
automatycznie te domeny, które są najczęściej wykorzystane przez
spamerów; umożliwienie kojarzenia indywidualnego IP nadawcy dla
poszczególnych nadawców oznacza konieczność rozbudowy systemu
zarządzania kontami; itd. itp. KOSZTY!

> A jak provider chce szybciutko sobie skonfigurowac, to moze wtawic po
> prosty * w dns-ie w miejscu loginow.

I tak musi to zrobić jeżeli ma loginy ze znakami niedowozwolonymi w
nazwach DNS (np. zawierające znak _)

> Daje to tez mozliwosc dopisania dla konkretnych e-maili innych zestawow
> relayow, jezeli klient z mailem j...@jakasdomena.pl korzysta np. ze swojego
> serwera smtp na sdi.

No fajnie, tylko jeszcze raz Ci przypomne, że żeby cos funkcjonowało to
musi być do tego oprogramowanie. I z takiego oprogramowania muszą
korzystać wszyscy zainteresowanie. Twoja propozycja stawia odnośnie
takiego oprogramowania zbyt wysokie wymagania.

> Zauwaz, ze RMX tez ma taka mozliwosc, ale uzywa z
> zalozenia niestandardowych rekordow dns i oznacza to, ze bez patchowania
> dns-ow nie jestes w stanie go porzadnie zastosowac.
> Poza tym rowniez pozwala na wildcardy.
>
>>> 2. Pozwala na uzywanie wildcardow jezeli chodzi o ip, a to oznacza, ze
>>> kazdy spamer ze swoja domena lub domena providera 'ofiary' moze to obejsc
>>> bez zadnego problemu.
>> wtedy wycinasz domenę. Dzieki zastosowaniu DMP masz pewność, że poczta
>> przychodzi z tych IP, które są desygnowane przez właściciela domeny, w
>> związku z tym *możesz* pociągać do odpowiedzialności na podstawie nazwy
>> domeny
>
> Jakie konsekwencje wyciagasz dla domen rejestrowanych na jeden wysyp
> spamu idacy przez open-proxy/zombie? DMP pozwala na wpisanie * w rekord
> opkreslajacy zakres adresow nadawcy, wiec spamera NIC nie kosztuje zrobic
> sobie rekord obejmujacy caly internet.

Nie widzę żadnego problemu. Celem DMP nie jest blokowanie, tylko
przywrócenie wiarygodności. Jeżeli nadawca jest wiarygodny (bo stosuje
DMP, a innych nasz system pocztowy nie bedzie przyjmować w ogóle gdy
system stanie się wystarczająco popularny, a może stać się popularny
ponieważ jedynym kosztem wdrożenia jest dopisanie niewielkiej liczby
rekordów w DNS) to możesz go blokować po nazwie domeny przy pomocy
tradycyjnych śródków - lokalna lista albo RBL (np *.a.biz.dmp.kropka.net
) Co więcej, jest możliwe zupełnie automatyczne dodawanie rekordów do
takiego RBLa ponieważ detekcja rekordów * w DMP jest trywialna.


B.

Bronek Kozicki

unread,
Feb 5, 2004, 5:53:49 AM2/5/04
to
On Thu, 5 Feb 2004 11:02:40 +0100, Marek Wodzinski wrote:

>> SPF, DMP etc. nie mają zabezpieczać przed spamem, czy wirusami.
>> To jest skutek uboczny.
>> Mają zabezpieczać przed fałszowaniem FROM w kopercie.
>> Tylko tyle.
>
> Jezeli sprawdzaja tylko domene, to nie wykorzystuja wszystkich (choc i tak
> bardzo skapych danych wejsciowych), to jest lekka rozrzutnosc i duzy
> margines bledu by-design.

Och, nie. To jest szacunek dla właściciela łącza, po którym ten ruch DNS
będzie przepychany, oraz dla nadawcy, który musi zapewnić istnienie
odpowiednich rekordów DNS. I nie ma *żadnego* marginesu błędu, ponieważ
system taki jak DMP dokładnie spełnia założenia (wiarygodność domeny
nadawcy) - podczas gdy Twój nie ma chyba żadnych sensowncyh założeń.


B.

Bronek Kozicki

unread,
Feb 5, 2004, 5:54:49 AM2/5/04
to
On Thu, 5 Feb 2004 11:25:58 +0100, Marek Wodzinski wrote:


>> Wpisywanie po kilka tysięcy adresów przez dużych (np. taki AOL),
>> a wpisanie 1 lini to jednak jest pewna różnica.
>
> Duzy moze zrobic sobie chocby dyndns-a, ktorego smtp wysylajacy
> uaktualnialby ipki dla danego adresu, wiec zapytanie zwracaloby tylko
> jeden ip lub kilka ostatnich ipkow. Zauwaz, ze dla az tak duzych
> providerow nie bedzie problemem zrobienie czegos takiego.

Wybacz, ale to twierdzenie jest śmieszne. Zajmowałeś się kiedyś
serwerem, który obsługuje chociaż 100 000 kont ?


B.

Dariusz Sznajder

unread,
Feb 5, 2004, 7:00:17 AM2/5/04
to
W artykule <Pine.LNX.4.58.04...@toster.pilczyce.net>
Marek Wodzinski napisał(a):
>> Elastyczność to zaleta - nie wada.
> Nie kosztem dziur i zlozonosci obliczeniowej (patrz chocby
> wiodacy OS).
Kosztem koszmaru administracyjnego tym bardziej.

> Wlasnie o to chodzi, ze rzezbic musieliby tylko naprawde bardzo duzi, bo

Żartujesz, prawda?

> Rzezbienie nie ma nic do RFC - w koncu RFC opisuje Ci tylko metode, a nie
> dostarcza zrodel do install>next>next>done.

Tak, tylko mam wrażenie, że póki co metoda zmienia się z dnia na dzień.

--
Dariusz Sznajder
DSZ1-RIPE

Marek Wodzinski

unread,
Feb 5, 2004, 6:58:43 AM2/5/04
to
On Thu, 5 Feb 2004, Bronek Kozicki wrote:

> On Thu, 5 Feb 2004 09:01:29 +0100, Marek Wodzinski wrote:
>
> >> On Wed, 4 Feb 2004 19:30:34 +0100, Marek Wodzinski wrote:
> >>> 1. Nie ma autoryzacji na poziomie loginu, a tylko po calej domenie
> >> odpowiedzialność administratora serwera , a nie poszczególnych userów.
> >> Jak wyobrażasz sobie wykorzystanie autoryzacji na poziomie loginu?
> >
> > Chodzi o to, ze jak przychodzi do Ciebie mail z powiedzmy
> > j...@jakasdomena.pl, to nie pytasz sie tylko czy list z jakasdomena.pl moze
> > przyjsc z tego relaya, ale czy list z j...@jakasdomena.pl moze z tamtad
> > przyjsc.
>
> Rozumiem. Po pierwsze: jaki jest cel takiego systemu?

Cel jest w temacie:-)

> W przypadku DMP
> tym celem jest przywrócenie wiarygodności domeny nadawcy. Włączając
> również największych providerów darmowych kont (bo z takich adresów
> wychodzi spora część światowego spamu). Cel Twojej propozycji jest
> niejasny. Nie da się jej zastosować dla ISP obsługującego miliony kont
> (w tym darmowych), bo musieliby oni zintegrować system obsługi kont z
> DNS.

Ale sam sama nie chce nikogo zmuszac do pelnej implementacji po stronie
nadawcy. Jak juz pisalem, z pewnych powodow ktos moze nie chcec lub nie
moc robic sprawdzenia per-user, wiec zrobi * i system sprowadzi sie do
tego co proponuja inne systemy, ale bedzie duzo prostszy z ograniczeniem
na brak wildcardow.

> > typu 127.x.x.x dla nieistniejacych skrzynek. Wtedy Ty odbierajac taka
> > poczte mozesz z czystym sumieniem wywalic do kosza maila z
> > jo...@jakasdomena.pl, bo tamten provider powiedzial Ci, ze takiej skrzynki
> > nie ma.
>
> ... a spamer zyskuje kolejne narzędzie harvestowania adresów. To już
> wygodniej włączyć obsługę VRFY

Na mydooma wystarczyloby, zeby w domenach podopisywac pojedyncze wpisy
127.x.x.x dla bill, brenda, john i wiekszosci slownika uzywanego przez
niego. Ot taki uklon w strone odbiorcy, zeby nie musial skanowac
antywirusem.

> > Jezeli jest kontrola nad cala informacja jaka podaje klient, to jest to
> > zawsze lepiej niz sprawdzanie tylko domeny.
>
> Nie rozumiem dlaczego. Koszt umożliwienia tego sprawdzania wyłącza
> automatycznie te domeny, które są najczęściej wykorzystane przez
> spamerów; umożliwienie kojarzenia indywidualnego IP nadawcy dla
> poszczególnych nadawców oznacza konieczność rozbudowy systemu
> zarządzania kontami; itd. itp. KOSZTY!

To nie jest koniecznosc, ale feature. Przy sprawdzaniu tylko domeny musisz
dodac wyjatki albo dla calej domeny, albo zrezydnowac z wyjatkow.

> > A jak provider chce szybciutko sobie skonfigurowac, to moze wtawic po
> > prosty * w dns-ie w miejscu loginow.
>
> I tak musi to zrobić jeżeli ma loginy ze znakami niedowozwolonymi w
> nazwach DNS (np. zawierające znak _)

To juz bylo poruszone i kwestia jest ewentualnie kodowania loginow.

> > Daje to tez mozliwosc dopisania dla konkretnych e-maili innych zestawow
> > relayow, jezeli klient z mailem j...@jakasdomena.pl korzysta np. ze swojego
> > serwera smtp na sdi.
>
> No fajnie, tylko jeszcze raz Ci przypomne, że żeby cos funkcjonowało to
> musi być do tego oprogramowanie. I z takiego oprogramowania muszą
> korzystać wszyscy zainteresowanie. Twoja propozycja stawia odnośnie
> takiego oprogramowania zbyt wysokie wymagania.

* w dns-ie?
Owszem, jak chcesz wykorzystac wszystkie mozliwosci, to mozesz sie
popisac, ale to przeciez i tak zalatwi jakikolwiek dns z baza danych jako
backend.

> >>> 2. Pozwala na uzywanie wildcardow jezeli chodzi o ip, a to oznacza, ze
> >>> kazdy spamer ze swoja domena lub domena providera 'ofiary' moze to obejsc
> >>> bez zadnego problemu.
> >> wtedy wycinasz domenę. Dzieki zastosowaniu DMP masz pewność, że poczta
> >> przychodzi z tych IP, które są desygnowane przez właściciela domeny, w
> >> związku z tym *możesz* pociągać do odpowiedzialności na podstawie nazwy
> >> domeny
> >
> > Jakie konsekwencje wyciagasz dla domen rejestrowanych na jeden wysyp
> > spamu idacy przez open-proxy/zombie? DMP pozwala na wpisanie * w rekord
> > opkreslajacy zakres adresow nadawcy, wiec spamera NIC nie kosztuje zrobic
> > sobie rekord obejmujacy caly internet.
>
> Nie widzę żadnego problemu. Celem DMP nie jest blokowanie, tylko
> przywrócenie wiarygodności.

Jak widzisz cel jest inny, chociaz implementacja bardzo podobna.

Marek Wodzinski

unread,
Feb 5, 2004, 7:12:18 AM2/5/04
to
On Thu, 5 Feb 2004, Dariusz Sznajder wrote:

> W artykule <Pine.LNX.4.58.04...@toster.pilczyce.net>
> Marek Wodzinski napisał(a):
> >> Elastyczność to zaleta - nie wada.
> > Nie kosztem dziur i zlozonosci obliczeniowej (patrz chocby
> > wiodacy OS).
> Kosztem koszmaru administracyjnego tym bardziej.

Czy to co robia wirusy i spamerzy nazywasz sielanka?
Protokol smtp jest i tak dziurawy. Nie ma sensu wymyslac armaty na muchy
jezeli jedynym wyjsciem jest i tak zmigrowanie na inny sprosob
dostarczania poczty.

> > Wlasnie o to chodzi, ze rzezbic musieliby tylko naprawde bardzo duzi, bo
> Żartujesz, prawda?

Inaczej: s/musieliby/mogliby/

> > Rzezbienie nie ma nic do RFC - w koncu RFC opisuje Ci tylko metode, a nie
> > dostarcza zrodel do install>next>next>done.
> Tak, tylko mam wrażenie, że póki co metoda zmienia się z dnia na dzień.

Co sie zmienilo od mojego pierwszego postu?
Gdzie napisalem, ze nie moze z tego powstac RFC?

Bronek Kozicki

unread,
Feb 5, 2004, 7:25:48 AM2/5/04
to
On Thu, 5 Feb 2004 12:58:43 +0100, Marek Wodzinski wrote:
> Cel jest w temacie:-)

No tak, tylko że do tego idealnie nadaje się również DMP czy SPF, które
są znacznie tańsze w implementacji.

> Na mydooma wystarczyloby, zeby w domenach podopisywac pojedyncze wpisy
> 127.x.x.x dla bill, brenda, john i wiekszosci slownika uzywanego przez

a po co? A nie lepiej (bardziej uniwersalnie) w ogóle nie przyjmować
poczty z IP które nie są autoryzowanymi nadawcami dla domeny?

> * w dns-ie?
> Owszem, jak chcesz wykorzystac wszystkie mozliwosci, to mozesz sie
> popisac, ale to przeciez i tak zalatwi jakikolwiek dns z baza danych jako
> backend.

Uch, och, musiałbyś jeszcze namówić zainteresowanych do stosowania
takich DNS.

B.

PiK

unread,
Feb 6, 2004, 7:33:11 AM2/6/04
to
Użytkownik "Marek Wodzinski" <ma...@ODSPAMIACZ.mamy.to> napisał w wiadomości
news:Pine.LNX.4.58.04...@toster.pilczyce.net...

>>> 2. Pozwala na uzywanie wildcardow jezeli chodzi o ip, a to oznacza, ze
>>> kazdy spamer ze swoja domena lub domena providera 'ofiary' moze to
obejsc
>>> bez zadnego problemu.

>> A gdzie w Twojej propozycji jest zabezpieczenie przed tym?
>
> Po prostu nie wpiszesz do dns-a calego internetu...
> Jezeli nie ma mozliwosci stosowania wildcardow, to tej mozliwosci nie
> naduzyjesz. RMX, DMP czy SPF nie sa zadna przeszkoda dla spamera z
> kolejna wlasna domena do czasu jej usuniecia. Po usunieciu i tak wiekszosc
> mta juz tego nie przyjmie...

Widzisz, mozliwości stosowania wildcardów w DMP nie wprowadzono przypadkowo.
Ale ty chyba nie doczytałeś tego draftu do końca. Wilddacrd jest po to aby
mozna było wprowadzić rekord typu
*._smtp-client TXT "dmp=deny"

A jedyna mozliwoscią zastosowania tej metody w proponowany przez ciebie
sposób jest desygnowanie _dokładnie_ całego internetu jako autoryzowanego
*.in-addr._smtp-client TXT "dmp=allow"

Punkt 9.3 draftu stanowi wyraźnie, że po napotkaniu takiego rekordu mozna
po prostu odmówić przyjmowania maili z takiej domeny.

Tylko że ty wciąż nie rozumiesz po co jest DMP. To nie jest uniwersalne
remedium na spam. To jest narzedzie do uwiarygodnienia _twojej_ domeny, nie
internetu. To jest narzędzie pozwalajace poinformowac odbiorców, że za maile
z _twojej_ domeny _ty_ jesteś odpowiedzialny. Może oznaczać także, ze za
maile z domeny spamera odpowiedzialny jest on sam. Ale niech sobie
wpisze i cały internet jak chce. Ja nie musze przyjmowac maili od niego. Że
może sobie kupić nową domenę? A tak! O to chodzi. Niech kupuje. Niech
zapłaci. W tej chwili nie płaci, bo używa _twojej_ (mojej, cudzej) domeny.
Czy to zlikwiduje spam? Nie. Nie znam rozwiązania likwidującego spam. O DMP
napisałem dlatego, że jest rozwiązaniem bardziej zaawansowanym (w sensie
procesu powstania) niż twoje. Były już jakies konsultacje z tymi naprawdę
"dużymi", wyrazili swoje zainteresowanie, trwa proces zatwierdzania RFC.

Napisałes ze i twoje może doczekac się RFC. Oczywiście, może. Spróbuj. Może
zdziwisz się ile trzeba zrobić żeby przeszło. W kazdym razie rozwiązanie
umożliwiające weryfikację istnienia kont _chyba_ nie przejdzie. A tak przy
okazji. Prób stworzenia uniwersalnego rozwiązania było już tak wiele, ze
spamerzy utworzyli też uniwersalny LART przeciwko nim. Poniżej LART
przeciwko
DMP (z listy DMP). Zastanow się nad wadami swojego (choćby odnosząc się do
zarzutów poniżej).

PiK
-----------------


Your company advocates a

(x) technical ( ) legislative ( ) market-based ( ) vigilante

approach to fighting spam. Your idea will not work. Here is why it won't
work. (One or more of the following may apply to your particular idea, and
it may have other flaws which used to vary from state to state before a bad
federal law was passed.)

( ) Spammers can easily use it to harvest email addresses
(x) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential
employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
(x) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
(x) Extreme stupidity on the part of people who do business with spammers
( ) Extreme stupidity on the part of people who do business with Microsoft
( ) Extreme stupidity on the part of people who do business with Yahoo
(x) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook

and the following philosophical objections may also apply:

(x) Ideas similar to yours are easy to come up with, yet none have ever been
shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough

Furthermore, this is what I think about you:

(x) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid company for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!

Dariusz Sznajder

unread,
Feb 6, 2004, 8:48:22 AM2/6/04
to
W artykule <c00280$m9r$1...@srv.cyf-kr.edu.pl>
PiK napisał(a):

> procesu powstania) niż twoje. Były już jakies konsultacje z tymi naprawdę
> "dużymi", wyrazili swoje zainteresowanie, trwa proces zatwierdzania RFC.
Tak a'propos dużych:
darek@dom ~ $ host -t txt aol.com
aol.com text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24
ip4:205.188.144.0/24 ip4:205.188.156.0/24 ip4:205.188.157.0/24
ip4:205.188.159.0/24 ip4:64.12.136.0/24 ip4:64.12.137.0/24
ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

:)

--
Dariusz Sznajder
DSZ1-RIPE

0 new messages