Protokół komunikacyjny [było - Walka ze spamem]

30 views
Skip to first unread message

Paweł Kierski

unread,
Jun 12, 2006, 3:51:26 AM6/12/06
to
Takie moje przemyślenia z kilku postów, w których już zaczęło się
prawie projektowanie protokołu... 8-)

Jesteśmy wszyscy dość mocno przywiązani do poczty w mniej więcej
obecnej postaci. Ale jednocześnie są IM, które coraz bardziej się
rozwijają, jest VoIP, będą jeszcze inne usługi "wciskane" w tę samą
infrastukturę TCP/IP.

W gruncie rzeczy chodzi o to, żeby komunikacja każdego z każdym była
"lekka, łatwa i przyjemna", a jednocześnie żeby nie być narażonym na
nagabywanie - obojętne, czy viagrą, czy "głosuj na nas", czy
łańcuszkiem, czy "cze skont klikash".

Tak mi z wychodzi, że przydałby się system zbliżony do DNS, ale
będący serwisem nazw odbiorców (pomysł z przenoszeniem skrzynek z
zachowaniem adresu w końcu kiedyś wyjdzie, tak jak przy telefonach,
problem z numerami "premium" w GG już był). Odpowiednio zaprojektowany
załatwiałby kilka spraw:
1. Jednolity system nazewnictwa.
2. "Przezroczystość" komunikacji bez względu na protokół
komunikacyjny.
3. Autoryzację dostępu do odbiorcy (w tym ograniczenia dostępu).

Może najpierw widok od strony ZU.
Znam identyfikator kogoś, z kim chcę się skontaktować. Wybieram ten
identyfikator w programie komunikacyjnych i po chwili dostaję listę
możliwości, np. mogę teraz zadzwonić i rozmawiać głosowo, mogę
przesłać większy pakiet danych. Albo: użytkownik mocno zajęty - można
mu zostawić wiadomość (głosową, tekstową, większy pakiet danych).

Od strony "technicznej" - mniej więcej tak: dwie warstwy
- odpowiadająca za przypisanie identyfikator->serwer "kontaktowy"
- serwer "kontaktowy", którego protokół pozwala na:
- przedstawienie możliwych form komunikacji akceptowanych przez
odbiorcę
- autoryzację nadawcy (w tym ograniczenie dostępu do niektórych
form komunikacji)

Całość mogłaby być "nakładką" na obecne protokoły komunikacyjne -
takim "węzłem", dzięki któremu nie trzeba by kombinować, czy szukać
kogoś na ICQ, GG, mailu, Skype, a może formularza na jego stronie
domowej.

Na koniec kwestia najbardziej on-topic - czyli zabezpieczenie przed
spamem. Dostęp do danych kontaktowych (identyfikatorów w ramach
konkretnych protokołów) byłby chroniony w tym miejscu. W momencie,
kiedy nadawca decyduje się np. na wysłanie większej porcji danych,
serwer "kontaktowy" zanim poda np. e-maila, może np. zadać zagadkę,
poprosić o opłatę, przedstawienie się podpisem cyfrowym, czy co tam
też sobie odbiorca wymyślił. Jednocześnie odbiorca powinien mieć
możliwość przyznawania "darmowego" dostępu dla odpowiednio
identyfikujących się nadawców - np. przy subskrybcji newslettera
serwis generuje identyfikator jakim będzie się przedstawiał
subskrybentowi, a ten wpisuje go na swoją białą listę.

Wiem, że za tym kryje się mnóstwo szczegółów technicznych,
szczególnych przypadków itd. (choćby spamu na e-mail, "kryjący" się za
"globalnym" identyfikatorem - ale przecież tego e-maila można
bezboleśnie zmieniać co tydzień...). Chodziło mi tylko o
przedstawienie pewnego pomysłu, który byłby alternatywą dla
dziesiątków identyfikatorów, maili, nicków i numerów telefonów. W
końcu to technologia ma być dla użytkownika (który chce się
komunikować), a nie odwrotnie.
Jednocześnie zdaję sobie sprawę, że obecnych protokołów prawie nie
da się zmienić, a część z nich jest narażona na spamowanie by-design.
Dlatego taka propozycja - zebrania tych problemów (dostępności i
ograniczania dostępu) do kupy i rozwiązania ich w jednym miejscu.

--
Paweł Kierski
ne...@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)

Godryk

unread,
Jun 12, 2006, 5:28:29 AM6/12/06
to
Paweł Kierski pisze:

> Tak mi z wychodzi, że przydałby się system zbliżony do DNS, ale
> będący serwisem nazw odbiorców (pomysł z przenoszeniem skrzynek z
> zachowaniem adresu w końcu kiedyś wyjdzie, tak jak przy telefonach,
> problem z numerami "premium" w GG już był). Odpowiednio zaprojektowany
> załatwiałby kilka spraw:
> 1. Jednolity system nazewnictwa.
> 2. "Przezroczystość" komunikacji bez względu na protokół
> komunikacyjny.
> 3. Autoryzację dostępu do odbiorcy (w tym ograniczenia dostępu).

Tylko nie zapominajmy, że przenośność identyfikatora to kwestia drugorzędna
wobec problemów ze spamem/spimem. Najpierw niech to będzie protokół
umożliwiający komunikację każdego z każdym, ale tylko tak długo, jak długo
odbiorca zgadza się przyjmować wiadomości od nadawcy. (Czyli żeby można
było w kazdej chwili danego nadawcę zablokować).

> Może najpierw widok od strony ZU.
> Znam identyfikator kogoś, z kim chcę się skontaktować. Wybieram ten
> identyfikator w programie komunikacyjnych i po chwili dostaję listę
> możliwości, np. mogę teraz zadzwonić i rozmawiać głosowo, mogę
> przesłać większy pakiet danych. Albo: użytkownik mocno zajęty - można
> mu zostawić wiadomość (głosową, tekstową, większy pakiet danych).

Bardzo dobry pomysł.

> Od strony "technicznej" - mniej więcej tak: dwie warstwy
> - odpowiadająca za przypisanie identyfikator->serwer "kontaktowy"
> - serwer "kontaktowy", którego protokół pozwala na:
> - przedstawienie możliwych form komunikacji akceptowanych przez
> odbiorcę
> - autoryzację nadawcy (w tym ograniczenie dostępu do niektórych
> form komunikacji)
>
> Całość mogłaby być "nakładką" na obecne protokoły komunikacyjne -
> takim "węzłem", dzięki któremu nie trzeba by kombinować, czy szukać
> kogoś na ICQ, GG, mailu, Skype, a może formularza na jego stronie
> domowej.

Dokładnie tak. Pamiętajmy tylko, że trzeba będzie namówić jakoś na
współpracę właścicieli niektórych z tych protokołów - w tej chwili
w przypadku np. GG korzystanie z oprogramowania innego niz ich własne
jest nielegalne.

> Na koniec kwestia najbardziej on-topic - czyli zabezpieczenie przed
> spamem. Dostęp do danych kontaktowych (identyfikatorów w ramach
> konkretnych protokołów) byłby chroniony w tym miejscu. W momencie,
> kiedy nadawca decyduje się np. na wysłanie większej porcji danych,
> serwer "kontaktowy" zanim poda np. e-maila, może np. zadać zagadkę,
> poprosić o opłatę, przedstawienie się podpisem cyfrowym, czy co tam
> też sobie odbiorca wymyślił. Jednocześnie odbiorca powinien mieć
> możliwość przyznawania "darmowego" dostępu dla odpowiednio
> identyfikujących się nadawców - np. przy subskrybcji newslettera
> serwis generuje identyfikator jakim będzie się przedstawiał
> subskrybentowi, a ten wpisuje go na swoją białą listę.

Przy czym tu znowu: trzeba zdefiniować taki protokół, który umożliwi
odwołanie tej autoryzacji - czyli wyrzucenie identyfikatora z białej
listy. Może w ogóle nie ujawniać identyfikatorów konkretnych protokołów,
a tylko generowane (dla każdego nadawcy lub klasy nadawców)
identyfikatory tego naszego protokołu komunikacyjnego?

> Wiem, że za tym kryje się mnóstwo szczegółów technicznych,
> szczególnych przypadków itd. (choćby spamu na e-mail, "kryjący" się za
> "globalnym" identyfikatorem - ale przecież tego e-maila można
> bezboleśnie zmieniać co tydzień...). Chodziło mi tylko o

A tu akurat wystarczy domyślnie odciać cała pocztę, która przychodzi
bez postulowanego wcześniej przez Ciebie identyfikatora.

> przedstawienie pewnego pomysłu, który byłby alternatywą dla
> dziesiątków identyfikatorów, maili, nicków i numerów telefonów. W
> końcu to technologia ma być dla użytkownika (który chce się
> komunikować), a nie odwrotnie.

Tak jest.

> Jednocześnie zdaję sobie sprawę, że obecnych protokołów prawie nie
> da się zmienić, a część z nich jest narażona na spamowanie by-design.
> Dlatego taka propozycja - zebrania tych problemów (dostępności i
> ograniczania dostępu) do kupy i rozwiązania ich w jednym miejscu.

Tak jest. I wówczas - ale dopiero wówczas - można załatwić kwestię
przenośności identyfikatorów. Najlepszy byłby system możliwie
rozproszony i łatwo skalowalny. Dobrze by było w razie awarii jednego
serwera móc skorzystać z innego.

--
Godryk :: Tomek Marcinkowski :: http://godric.sf-f.pl
______________________________________________________________
>>> [ ...Jutro też wam uciekniemy! ] <<<

Marcin Kulas

unread,
Jun 12, 2006, 5:57:48 AM6/12/06
to
Godryk wrote:
> Tylko nie zapominajmy, że przenośność identyfikatora to kwestia drugorzędna
> wobec problemów ze spamem/spimem. Najpierw niech to będzie protokół
> umożliwiający komunikację każdego z każdym, ale tylko tak długo, jak długo
> odbiorca zgadza się przyjmować wiadomości od nadawcy. (Czyli żeby można
> było w kazdej chwili danego nadawcę zablokować).

Lub wręcz odwrotnie. Domyślnie blokada i dopisujemy do listy uprawnionej
do kontaktowania się z nami.

> Przy czym tu znowu: trzeba zdefiniować taki protokół, który umożliwi
> odwołanie tej autoryzacji - czyli wyrzucenie identyfikatora z białej
> listy. Może w ogóle nie ujawniać identyfikatorów konkretnych protokołów,
> a tylko generowane (dla każdego nadawcy lub klasy nadawców)
> identyfikatory tego naszego protokołu komunikacyjnego?

Hmmm, a może pójść dalej? Klient A może skontaktować się z klientem B,
o ile ten nie ma nic przeciwko, tylko i wyłącznie na adres będący haszem
IP serwera wysyłającego, adresu nadawcy oraz adresu odbiorcy[1].
Przy czym musi to być taki skrót, którego wygenerowanie zajmie odpowiednio
dużą ilość czasu (siła hasza może być definiowana przez odbiorcę). Żeby
uniezależnić się od mocy obliczeniowej komputerów, można powiązać ten
proces z koniecznością ściągnięcia czegoś z www, udzielenia odpowiedzi
na zagadkę, etc.
By nie cierpiały serwery odbiorcze podczas weryfikacji, skróty te mogłyby
być keszowane. Ale tutaj pojawia się ryzyko, że spamerzy również będą je
keszować, choć w tym przypadku ich zaboli dużo bardziej. Można pokusić się
o mechanizm ekspiracji haszy i zmuszania do ponownego ich generowania.


[1] Adres odbiorcy to adres bazowy, na który poczty wysłać nie można,
jeśli adresat sobie tego zażyczy, za to którym on się podpisuje przy
wysyłaniu poczty.

--
Marcin Kulas
jid: h...@jabbed.org

rezist.com

unread,
Jun 12, 2006, 6:01:05 AM6/12/06
to
> uniezależnić się od mocy obliczeniowej komputerów, można powiązać ten
> proces z koniecznością ściągnięcia czegoś z www, udzielenia odpowiedzi
> na zagadkę, etc.

Czuje sie jakbym czytal plik nfo na jakims trackerze z pornosami :>

Ja bym jednak postawil na przyjaznosc dla uzytkownika.

--
tomek nowak
http://rezist.com
http://anvilstrike.com
http://icic.pl

Paweł Kierski

unread,
Jun 12, 2006, 6:39:21 AM6/12/06
to
rezist.com w wiadomości <e6je11$1c3t$2...@sparrow.axelspringer.com.pl> pisze:

> > uniezależnić się od mocy obliczeniowej komputerów, można powiązać ten
> > proces z koniecznością ściągnięcia czegoś z www, udzielenia odpowiedzi
> > na zagadkę, etc.
>
> Czuje sie jakbym czytal plik nfo na jakims trackerze z pornosami :>
>
> Ja bym jednak postawil na przyjaznosc dla uzytkownika.

O to właśnie chodzi! 8-) Od strony użytkownika jak najmniej, to
program kliencki nadawcy ma znaleść sposoby dotarcia do odbiorcy i
przedstawić ew. koszta dotarcia (zagadki, formularze, płatności,
hashcash itp.). Chodzi o to, żeby za nie przywiązywać się do sposobu
obciążania zasobów nadawcy - lista algorytmów powinna być
rozszerzalna.
Z drugiej strony odbiorca musi łatwo konfigurować bariery dotarcia
do niego poszczególnymi kanałami (głosowym, tekstowym on-line,
tekstowym off-line). Założenie jest takie, że domyślna bariera (dla
nadawców nieznanych) jest wysoka, ale możliwa do pokonania.

Marcin Kulas

unread,
Jun 12, 2006, 8:10:08 AM6/12/06
to
Paweł Kierski wrote:
> O to właśnie chodzi! 8-) Od strony użytkownika jak najmniej, to
> program kliencki nadawcy ma znaleść sposoby dotarcia do odbiorcy i
> przedstawić ew. koszta dotarcia (zagadki, formularze, płatności,
> hashcash itp.). Chodzi o to, żeby za nie przywiązywać się do sposobu
> obciążania zasobów nadawcy - lista algorytmów powinna być
> rozszerzalna.
> Z drugiej strony odbiorca musi łatwo konfigurować bariery dotarcia
> do niego poszczególnymi kanałami (głosowym, tekstowym on-line,
> tekstowym off-line). Założenie jest takie, że domyślna bariera (dla
> nadawców nieznanych) jest wysoka, ale możliwa do pokonania.

Ale my szukamy chyba utopii. Albo coś jest niezauważalne dla ZU,
albo jest jednakowo upierdliwe dla komputerów o różnej mocy obliczeniowej.
Nie widzę sposobu obejścia tego problemu. No, może za wyjątkiem tokenów
czasowych przy autoryzacji.

Paweł Kierski

unread,
Jun 12, 2006, 8:22:55 AM6/12/06
to
Marcin Kulas w wiadomości <slrne8qmd...@jabbed.org> pisze:
[...]

> Ale my szukamy chyba utopii.

Owszem, czemu nie 8-)

> Albo coś jest niezauważalne dla ZU,
> albo jest jednakowo upierdliwe dla komputerów o różnej mocy obliczeniowej.
> Nie widzę sposobu obejścia tego problemu.

Chodzi o to, żeby była możliwość wyboru metody, niech uznanie
zdobędzie lepsza. Dodatkowo przerzucenie tego wyboru wprost na
odbiorcę - w końcu to najbardziej jemu powinno zależeć, czy jest
zalewany spamem, czy nie. Albo ustawia wysoki próg (testy Turinga) i
niektórzy mają mu to za złe ("bo ja nie wiem jak do Ciebie pisać..."),
albo zostawia hashcash, który jest możliwy do "przełamania" za pomocą
zombie.

> No, może za wyjątkiem tokenów czasowych przy autoryzacji.

Dla mnie to jedna z obowiązkowych cech - "zezwolenie" "wykupione"
metodami automatycznymi musi być czasowo ograniczone. I to nawet dość
mocno ograniczone.
Ale nic nie stoi na przeszkodzie, żeby odbiorca ustawił to sobie
inaczej, jeśli tylko łatwo da się te parametry definiować w protokole.

Godryk

unread,
Jun 12, 2006, 11:06:44 AM6/12/06
to
Marcin Kulas pisze:

> Godryk wrote:
>> Tylko nie zapominajmy, że przenośność identyfikatora to kwestia drugorzędna
>> wobec problemów ze spamem/spimem. Najpierw niech to będzie protokół
>> umożliwiający komunikację każdego z każdym, ale tylko tak długo, jak długo
>> odbiorca zgadza się przyjmować wiadomości od nadawcy. (Czyli żeby można
>> było w kazdej chwili danego nadawcę zablokować).
>
> Lub wręcz odwrotnie. Domyślnie blokada i dopisujemy do listy uprawnionej
> do kontaktowania się z nami.

Przecież napisałem wyraźnie: "[...] tak długo, jak długo odbiorca zgadza
się przyjmować [...]". Nie chodzi o to, ze domyślnie blokada, tylko żeby
raz udzieloną zgodę na otrzymywanie przesyłek mozna było w każdej chwili
odwołać - i w takim wypadku po prostu odbiorca blokowałby z powrotem
otrzymywanie poczty od danego nadawcy. SMTP tego nie gwarantuje na poziomie
protokołu: jeśli znasz czyjś adres, to możesz tam słać spam do uśmiechnietej
śmierci (fakt, że adresat go filtruje, to inna bajka).

>> Przy czym tu znowu: trzeba zdefiniować taki protokół, który umożliwi
>> odwołanie tej autoryzacji - czyli wyrzucenie identyfikatora z białej
>> listy. Może w ogóle nie ujawniać identyfikatorów konkretnych protokołów,
>> a tylko generowane (dla każdego nadawcy lub klasy nadawców)
>> identyfikatory tego naszego protokołu komunikacyjnego?
>
> Hmmm, a może pójść dalej? Klient A może skontaktować się z klientem B,
> o ile ten nie ma nic przeciwko, tylko i wyłącznie na adres będący haszem
> IP serwera wysyłającego, adresu nadawcy oraz adresu odbiorcy[1].

A to już jest zbyt skomplikowane - znaczy, jeśli masz udzielać zgody
na konkretny adres nadawcy, odbiorcy i serwer pośredniczący, to za Chiny
Ludowe nie da sie wprowadzić efektywnej przenośności adresów między serwerami.

--
Godryk :: Tomek Marcinkowski :: http://godric.sf-f.pl
______________________________________________________________

>>> Jeśli wszystko idzie dobrze, <<<
>>> to coś musiało zostać przeoczone. <<<

Marcin Kulas

unread,
Jun 12, 2006, 12:00:00 PM6/12/06
to
Godryk wrote:
> Marcin Kulas pisze:

> > Hmmm, a może pójść dalej? Klient A może skontaktować się z klientem B,
> > o ile ten nie ma nic przeciwko, tylko i wyłącznie na adres będący haszem
> > IP serwera wysyłającego, adresu nadawcy oraz adresu odbiorcy[1].
>
> A to już jest zbyt skomplikowane - znaczy, jeśli masz udzielać zgody
> na konkretny adres nadawcy, odbiorcy i serwer pośredniczący, to za Chiny
> Ludowe nie da sie wprowadzić efektywnej przenośności adresów między serwerami.

Chyba, że z punktu widzienia ZU zgoda dotyczyłaby słania z adresu A na
(jego) adres B, a serwer wystawiałby (póki user B nie zmieni zdania)
okresowe hasze autoryzujące. Nie wiem. Prawdę mówiąc, ciężko mi sobie
wyobrazić nowy protokół, który przeżyłby kolejną dekadę bez zgwałcenia
go przez ludzi życzliwych inaczej.

Sergiusz Rozanski

unread,
Jun 12, 2006, 1:00:39 PM6/12/06
to

Zróbmy taki, abyśmy się nie musieli go wstydzić, tak jak Ci od smtp :D
Wasze wywody mi sie podobają, to musiało by miec coś z protokołu finger.
Będę nad tym myślał :)

--
*** rozanski.at.sergiusz.dot.com sq3bkn ***
*** http://jeep.comm.pl ***
*** rtg project http://gg.overwap.net ***

Pawel S.

unread,
Jun 12, 2006, 2:34:58 PM6/12/06
to
Godryk wrote:

> Tylko nie zapominajmy, że przenośność identyfikatora to kwestia
> drugorzędna wobec problemów ze spamem/spimem. Najpierw niech to będzie
> protokół umożliwiający komunikację każdego z każdym, ale tylko tak długo,
> jak długo odbiorca zgadza się przyjmować wiadomości od nadawcy. (Czyli
> żeby można było w kazdej chwili danego nadawcę zablokować).

hmm, ipv6 + firewall?

ustawiam domyslnie drop + kilka acceptow na adresy znajomych
i nie ogladam wiecej zadnych polaczen ktorych nie chce.
pozostaje tylko kwestia jak zwiazac adres ipv6 z ludziem.

Godryk

unread,
Jun 12, 2006, 2:43:53 PM6/12/06
to
Pawel S. pisze:

Znowu sięganie lewą ręką do prawej kieszeni. Gdzie adres IP (nawet
ipv6), gdzie transport wiadomości? ;-) Bo to tylko rozszerzenie
zwykłego blokowania na firewallu. W ten sposób wyjdzie potworek
gorszy od M$cokolwiek. ;->

Owszem, pi razy oko tak to będzie działać, tylko w zupełnie innej
warstwie...

--
Godryk :: Tomek Marcinkowski :: http://godric.sf-f.pl
______________________________________________________________

>>> [ que se leve celui qui leur lance la pierre ] <<<
>>> [ il ne sait de l'amour que le verbe s'aimer ] <<<

Pawel S.

unread,
Jun 12, 2006, 2:58:37 PM6/12/06
to
Godryk wrote:

> Owszem, pi razy oko tak to będzie działać, tylko w zupełnie innej
> warstwie...

przy ipv4 wycinajac jeden adres mozesz wybic swoich klientow i wrogow.
jesli ludzie na ziemi beda miec przypisane swoje klasy ipv6
(byc moze jakos zwiazane z certyfikatami), to imho ipv6 + ipsec +
jakis przyjazdny uzyszkodnikom interfejs do firelola moze skutecznie
ukrocic niechciana komunikacje wszelkiej masci.

Sergiusz Rozanski

unread,
Jun 12, 2006, 4:56:16 PM6/12/06
to

A jak będzie chciał do mnie napisać ktoś nieznajony to skąd jego ip
się znajdzie u mnie w fw?
Niee.
Ja ze swej strony uważam że potworkiem jest mass-mailing i chcę się
od niego (jako user) odciąć, z jego zaletami (listy dyskusyjne,
newslettery, respondery, potwierdzenia zapisu na... itp) i wadami (spam).
Chcę aby mi to protokół gwarantował, ipv6 nic tu raczej nie pomoże,
koncepcja z rozproszoną informacją o uzytkowniku mi się podoba,
wyobrażam sobie to jako server na domenie, aby uzyskać wjazd trzeba się
przedstawić (podać swój identyfikator) i 'zapłacić', a uzyskane dane będą
zawierały typowe cele kontaktu cyfrowego, bieżące np smtp w klasycznej
formie, a np nowe smtp będzie zawierało ciacho+sender+recipient itp.

O ile problemem nie jest 'sprzedanie' informacji o kontakcie i tu
można przedyskutować w jakiej formie to zwracać, to główną barierą
jest 'zapłata' za dostęp do danych kontaktowych.
Klient poczty musi umieć pobrać dane i mieć zaimplementowane typowe
'standardowe' formy zapłaty.

Osobiście ze swej strony widzę kilka form płatności do implementacji
na start:
- za darmo
- test turinga graficzny
- test turinga audio
- test turinga tekstowy
- token mikropłatności

Pawel S.

unread,
Jun 12, 2006, 5:20:34 PM6/12/06
to
Sergiusz Rozanski wrote:

> Dnia 12.06.2006 Pawel S. <root@[127.0.0.1]> napisał/a:
>> Godryk wrote:
>>
>>> Owszem, pi razy oko tak to będzie działać, tylko w zupełnie innej
>>> warstwie...
>>
>> przy ipv4 wycinajac jeden adres mozesz wybic swoich klientow i wrogow.
>> jesli ludzie na ziemi beda miec przypisane swoje klasy ipv6
>> (byc moze jakos zwiazane z certyfikatami), to imho ipv6 + ipsec +
>> jakis przyjazdny uzyszkodnikom interfejs do firelola moze skutecznie
>> ukrocic niechciana komunikacje wszelkiej masci.
>
> A jak będzie chciał do mnie napisać ktoś nieznajony to skąd jego ip
> się znajdzie u mnie w fw?

zmienisz domyslna polityke firelola?

> O ile problemem nie jest 'sprzedanie' informacji o kontakcie i tu
> można przedyskutować w jakiej formie to zwracać, to główną barierą
> jest 'zapłata' za dostęp do danych kontaktowych.
> Klient poczty musi umieć pobrać dane i mieć zaimplementowane typowe
> 'standardowe' formy zapłaty.

na samo slowo "zaplata za maila" ludzie odejda od tej uslugi.
jak dziennie ktos odbiera kilkadziesiat maila z roznych grup dyskusyjnych,
to sie nie "wyplaci". pozniej moze nastepna bedzie oplata za korzystanie
z www? wolne zarty.

> Osobiście ze swej strony widzę kilka form płatności do implementacji
> na start:
> - za darmo
> - test turinga graficzny
> - test turinga audio
> - test turinga tekstowy
> - token mikropłatności

i myslisz, ze bede n-razy wypelnial jakis test jesli chce wyslac
znajomym info o najblizszej imprezie? ;-)

Sergiusz Rozanski

unread,
Jun 12, 2006, 5:29:58 PM6/12/06
to
Dnia 12.06.2006 Pawel S. <root@[127.0.0.1]> napisał/a:
> Sergiusz Rozanski wrote:
>
>> Dnia 12.06.2006 Pawel S. <root@[127.0.0.1]> napisał/a:
>>> Godryk wrote:
>>>
>>>> Owszem, pi razy oko tak to będzie działać, tylko w zupełnie innej
>>>> warstwie...
>>>
>>> przy ipv4 wycinajac jeden adres mozesz wybic swoich klientow i wrogow.
>>> jesli ludzie na ziemi beda miec przypisane swoje klasy ipv6
>>> (byc moze jakos zwiazane z certyfikatami), to imho ipv6 + ipsec +
>>> jakis przyjazdny uzyszkodnikom interfejs do firelola moze skutecznie
>>> ukrocic niechciana komunikacje wszelkiej masci.
>>
>> A jak będzie chciał do mnie napisać ktoś nieznajony to skąd jego ip
>> się znajdzie u mnie w fw?
>
> zmienisz domyslna polityke firelola?

??? a niby skąd będę wiedział kto kiedy?

>> O ile problemem nie jest 'sprzedanie' informacji o kontakcie i tu
>> można przedyskutować w jakiej formie to zwracać, to główną barierą
>> jest 'zapłata' za dostęp do danych kontaktowych.
>> Klient poczty musi umieć pobrać dane i mieć zaimplementowane typowe
>> 'standardowe' formy zapłaty.
>
> na samo slowo "zaplata za maila" ludzie odejda od tej uslugi.

formy dostepu do danych

> jak dziennie ktos odbiera kilkadziesiat maila z roznych grup dyskusyjnych,
> to sie nie "wyplaci". pozniej moze nastepna bedzie oplata za korzystanie
> z www? wolne zarty.

płacisz pośrednio za wysyłanie, nie za odbiór

>> Osobiście ze swej strony widzę kilka form płatności do implementacji
>> na start:
>> - za darmo
>> - test turinga graficzny
>> - test turinga audio
>> - test turinga tekstowy
>> - token mikropłatności
>
> i myslisz, ze bede n-razy wypelnial jakis test jesli chce wyslac
> znajomym info o najblizszej imprezie? ;-)

nie no czemu, wystarczy jedna, a jak znajomy da swój adres za free to
wogóle pozostanie za darmo. Odbiorca ustala cene swojego adresu,
jak za darmo to nic nie płacisz, jak chce token to musisz go
przepisać itp.

wer

unread,
Jun 12, 2006, 6:14:51 PM6/12/06
to
Sergiusz Rozanski wrote:
>>>- token mikropłatności
>>
>>i myslisz, ze bede n-razy wypelnial jakis test jesli chce wyslac
>>znajomym info o najblizszej imprezie? ;-)
>
>
> nie no czemu, wystarczy jedna, a jak znajomy da swój adres za free to
> wogóle pozostanie za darmo. Odbiorca ustala cene swojego adresu,
> jak za darmo to nic nie płacisz, jak chce token to musisz go
> przepisać itp.
>

Co nie zlikwiduje problemu zombie i wirusow, ktore sie instaluja i
wysylaja jako user na podstawie jego ksiazki adresowej.

wer

Paweł Kierski

unread,
Jun 13, 2006, 3:36:38 AM6/13/06
to
Użytkownik "wer" <arx...@o2.pl> napisał w wiadomości
news:e6koum$2od$1...@news.supermedia.pl...
[...]

>> nie no czemu, wystarczy jedna, a jak znajomy da swój adres za free to
>> wogóle pozostanie za darmo. Odbiorca ustala cene swojego adresu,
>> jak za darmo to nic nie płacisz, jak chce token to musisz go
>> przepisać itp.
>>
>
> Co nie zlikwiduje problemu zombie i wirusow, ktore sie instaluja i
> wysylaja jako user na podstawie jego ksiazki adresowej.

Gruby dowcip - identyfikacja znajomych nie może odbywać się
na podstawie adresu (identyfikatora), ale bardziej wiarygodnych
form. Może to być podpis cyfrowy, a może być sekret (hasło)
przekazane nadawcy po pierwszym kontakcie. Byle protokół
dostarczał różnych i łatwo definiowalnych metod. Wiarygodne
potwierdzenie swojej (będącej na liście "znajomych") tożsamości
byłoby jedną z metod autoryzacji. Inne mogą być anonimowe, bo
wymagają zaangażowania zasobów. Oczywiście metody podatne na
"podkradanie" (np. hashcash) przez zombie będą mniej skuteczną
zaporą.

Paweł Kierski
ne...@pkierski.net

Sergiusz Rozanski

unread,
Jun 13, 2006, 4:51:40 AM6/13/06
to

Proponuję zmianę indentyfikatora na @@ (atat) czyli postać np:
serek@@tld.pl aby wiadomo było o co chodzi i że nie traktujemy
go jako adres email.
W dns domeny tld.pl umieszony byłby adres servera danych
kontaktowych w postaci powiedzmy
_atat._tcp.tld.pl. IN SRV 5 0 3333 atat.tld.pl.
_atat._tcp.tld.pl. IN SRV 10 0 3333 backup.atat.tld.pl.

Klient poczty, im, voip itp łączyłby się na ten host:port i
zapewniał odbiór docelowych adresów po spełnieniu wymogów
narzuconych przez właściciela skrzynki.
Sesja mogła by wyglądac np tak:

> ATAT server tld.pl login:
< ania@@a.tld.pl
> OK select method
> FREE
> TURINGTXT
> TURINGGRAPH
> TURINGAUDIO.
< TURINGGRAPH
> image/gif 2789 nhjnhhh7*(YTN&GNygnfy(2789 bajtów gifa)bgG^&BG^gy
> enter data:
< przepisanygif
> smtp:ser...@tld.pl
> smtp:ser...@tld.pl
> nsmtp:ciachodostepuzzakodow...@tld.pl
> gg:1234567
> xmpp:se...@tld.pl
> phone:2345678
> :
< QUIT

tak to bym mniej więcej widział :)

Dzięki temu mogę sobie zmieniać adres pocztowy jak chce, a ktoś kto
zna mój atat zwasze mnie znajdzie, ale po spełnieniu moich warunków :)
Mam tylko nadzieje że pozytronowe mózgi potrafią zapamiętać dodatkowe
prawo robotyki :D 'Nie będę spamował'.

Godryk

unread,
Jun 13, 2006, 5:35:08 AM6/13/06
to
Paweł Kierski pisze:

Przede wszystkim: OIDP wirusy nie korzystają z MUA, a tylko z ksiażki
adresowej. Wiec można by było dodać autoryzację każdego MUA przy wysyłce
- choćby klucz prywatny do podpisywania wiadomości, przechowywany na dysku,
ale chroniony hasłem, które użytkownik musi wpisać przy każdym odpaleniu
MUA. Wirus tego nie przejdzie. A i tak musimy mieć jakąś formę autoryzacji
użytkownika (więc i jego MUA) przy wysyłce.

Aby nie było problemów z przenośnością adresu, można by założyć, ze każdy
użytkownik deponuje swój klucz publiczny na co najmniej jednym serwerze
(najlepiej na kilku, na wypadek awarii jednego) i tylko te serwery
przyjmują od niego przesyłki. W przypadku zmiany serwera jest to kwestia
przeniesienia klucza na nowy/nowe serwer/y.

Odniosę się jeszcze do pomysłu "opłat" za wysyłkę.

Pomysł z opłatami w formie zagadek czy czasu procesora ma tę wadę, że
spamer mógłby do rozwiazywania zagadek zatrudnić np. armię niskopłatnych
pracowników. Jeśli zagadka nie miałaby zniechęcać zwykłego użytkownika,
jej rozwiązanie musiałoby trwać najwyżej kilkanaście sekund.

Skalkulujmy: licząc po 20 s na zagadkę i przyjmując koszt zatrudnienia
pracownika na poziomie 1200 zł miesięcznie, spamer może rozesłać
ok. 1500 maili dziennie (30 tys. miesięcznie) - a więc kosztuje go to
ok. 3 gr za pojedyńczy spam. To i tak o wiele taniej, niż wysyłka
oferty pocztą lub faksem! Żeby koszt zagadki był zaporowy, musiałby być
porównywalny z opłatami za faks (ok. 30 gr), czyli przynajmniej
dziesięciokrotnie wyższy. Czyli rozwiazanie zagadki musiałoby zajmować
ok. 3 minut. A na to zwykli użytkownicy się po prostu nie zgodzą...

I tu przychodzi mi do głowy inna myśl: a moze by tak wbudować w protokół
odpowiedzialność użytkowników za nadużycia, choćby poprzez czasową
blokadę wysyłki - i odpowiednio, blokowania serwerów, które nie blokują
użytkowników dokonujących nadużyć?

Takie mechanizmy kontroli zachowania użytkowników nie są ograniczaniem
praw użytkowników, bo korzystanie z tego protokołu nie jest obowiązkowe;
przeciwnie, korzystanie z taniej komunikacji przy użyciu takiego
protokołu jest przywilejem. Jeśli użytkownik nadużyje przywileju,
zostanie mu on odebrany - i pozostanie mu wówczas tylko płatna komunikacja,
np. zwykłą papierową pocztą.

Mam pewien pomysł idący w tym kierunku, mogę go przedstawić, jesli chcecie.

--
Godryk :: Tomek Marcinkowski :: http://godric.sf-f.pl
______________________________________________________________

>>> [ pulchrum est quod visu placet ] <<<

DM

unread,
Jun 13, 2006, 6:03:36 AM6/13/06
to
Godryk wrote:

> ale chroniony hasłem, które użytkownik musi wpisać przy każdym

Ludzie sa zbyt leniwi i ida na latwizne.

> Mam pewien pomysł idący w tym kierunku, mogę go przedstawić, jesli
> chcecie.

Chetnie :)

Pzdr
DM

Sergiusz Rozanski

unread,
Jun 13, 2006, 6:07:39 AM6/13/06
to
Dnia 13.06.2006 Godryk <god...@sf-f.pl> napisał/a:
>
> Mam pewien pomysł idący w tym kierunku, mogę go przedstawić, jesli chcecie.

O tak, dawaj, narazie każdy pomysł się liczy.

Godryk

unread,
Jun 13, 2006, 6:08:56 AM6/13/06
to
DM pisze:

> Godryk wrote:
>
>> ale chroniony hasłem, które użytkownik musi wpisać przy każdym
>
> Ludzie sa zbyt leniwi i ida na latwizne.

Hm. Niby tak, ale nawet jeśli MUA będzie sobie gdzieś te hasła
przechowywać (jak obecnie hasła do skrzynek) to i tak trzeba się
o wiele bardziej napracować, zeby napisać wirusa, który to złamie.

Poza tym, w wypadku wykrycia rozsyłki wirusa można by wprowadzić
obowiazek nieprzyjmowania przez serwer wiadomości od tego użytkownika.

--
Godryk :: Tomek Marcinkowski :: http://godric.sf-f.pl
______________________________________________________________

Dariusz Sznajder

unread,
Jun 13, 2006, 6:32:04 AM6/13/06
to
Dnia 12.06.2006 Paweł Kierski <ne...@pkierski.net> napisał/a:
> zdobędzie lepsza. Dodatkowo przerzucenie tego wyboru wprost na
> odbiorcę - w końcu to najbardziej jemu powinno zależeć, czy jest
Dość chyba naiwnie zakładasz wysoką świadomość odbiorcy i
ubezwłasnowolnienie nadawcy.

Nie zawsze i nie tylko nadawca wiadomości ma interes w tym, żeby
ona dotarła. Choćby ostatnio było dość głosno o stratach jakiejstam
szkoły z powodu antyspamu i zatrzymania - chcianej przecież - oferty.
Jak odpisuje prywatnie na post z Usenetu i spotykam po drodze jakies
przeszkody to też po prostu nie odpisze. I nie ja będę mial nie
rozwiązany problem.
Więc odbiorcy też zalezy, żeby coś dostać.

A Ty zakładasz, że on sobie świadomie wyłaczy ochronę, jak mu będzie
zależało i właczy jak przestanie.
Ilu będzie takich?
Ilu teraz to robi dla różnych dziwnych wynalazków antyspamowych?

--
Dariusz Sznajder
DSZ1-RIPE

Paweł Kierski

unread,
Jun 13, 2006, 6:35:02 AM6/13/06
to
Godryk w wiadomości <slrne8t1mc...@godric.was.here> pisze:
[...]

> Skalkulujmy: licząc po 20 s na zagadkę i przyjmując koszt zatrudnienia
> pracownika na poziomie 1200 zł miesięcznie, spamer może rozesłać
> ok. 1500 maili dziennie (30 tys. miesięcznie) - a więc kosztuje go to
> ok. 3 gr za pojedyńczy spam. To i tak o wiele taniej, niż wysyłka
> oferty pocztą lub faksem! Żeby koszt zagadki był zaporowy, musiałby być
> porównywalny z opłatami za faks (ok. 30 gr), czyli przynajmniej
> dziesięciokrotnie wyższy. Czyli rozwiazanie zagadki musiałoby zajmować
> ok. 3 minut. A na to zwykli użytkownicy się po prostu nie zgodzą...

Dowcip polega na tym, że każdy odbiorca może sobie próg ustawiać
wedle własnego widzimisię. Może ustawić zagadkę na 5 sekund, może na 5
minut - najwyżej jego znajomi piszący pierwszy raz mogą się
zdenerwować i obrazić. Za to spamu raczej mieć nie będzie...
W końcu największe sukcesy odnoszą ponoć obecnie techniki oparte na
aktywnym udziale użytkowników - wiki, blogi, katalogi linków z
tagowaniem itp. Samodzielne wyznaczanie progu "ostrości" filtrów to
ten sam kierunek.

futszaK

unread,
Jun 13, 2006, 6:46:53 AM6/13/06
to
Mon, 12 Jun 2006 09:57:48 +0000 (UTC), użyszkodnik Marcin Kulas
<0...@jabbed.org> napisał:

> dużą ilość czasu (siła hasza może być definiowana przez odbiorcę). Żeby
> uniezależnić się od mocy obliczeniowej komputerów, można powiązać ten
> proces z koniecznością ściągnięcia czegoś z www,

wiesz czemu nie trawie forów dyskusyjnych a siedze na usenecie ???
bo tu nie musze klikać i chodzić po jakichś www na których nie wiadomo
co jest, krew mnie zalewa jak jakiś skypepodobny program bez mojego
pytania otwiera jakąś strone www z migającymi bannerkami gdzie
potencjalnie coś mi się przyklei do systemu


--
futszaK
601061867
kumpel był zachwycony wokalistką Tokio Hotel, dopóki
mu nie powiedziałam, że to chłopiec jest :P (c)Lilu

Godryk

unread,
Jun 13, 2006, 11:46:08 AM6/13/06
to
Sergiusz Rozanski pisze:

> Dnia 13.06.2006 Godryk <god...@sf-f.pl> napisał/a:
>>
>> Mam pewien pomysł idący w tym kierunku, mogę go przedstawić, jesli chcecie.
>
> O tak, dawaj, narazie każdy pomysł się liczy.

Na razie myślę tak: protokół powinien być modularny i umożliwiać
różne implementacje sposobu autoryzacji lub "opłaty" za dotarcie
do odbiorcy. Czy przy każdym kontakcie, czy tylko przy pierwszym,
czy "drożej", czy "taniej" - to wszystko są szczegóły, które
docelowo powinien ustawiać użytkownik, znaczy - potencjalny odbiorca.

Problem w tym, że samo ustawianie będzie pracochłonne. Trzeba więc
będzie ustawić jakieś defaultowe wartości, które pewnie będą
wykorzystane przez 95% użytkowników.

Poza tym, sama złożoność różnych technik - choćby zadawania zagadek
(obrazek, tekst, dźwięk) spowoduje, że implementacja będzie skomplikowana.

Zacząłem sie więc zastanawiać nad "wbudowaniem w protokół" odpowiedzialności
użytkowników i administratorów.

Chodzi mi o to, żeby raportowanie przypadków spamu (lub wirusów) oraz źle
skonfigurowanych serwerów było częścią protokołu, oraz żeby pewne działania
były podejmowane automatycznie przez oprogramowanie serwera, aż do odwołania
ich przez administratora (np. w wypadku blokady przyjmowania przesyłek
z zawirusowanego systemu - odblokowanie na wniosek użytkownika). Ponadto
żeby administrator również ponosił odpowiedzialność za błędne decyzje,
skutkującą odmową przyjmowania poczty z jego serwera.

Na razie uważam, że sensowny protokół powinien spełniać następujące
założenia:

0) wszystkie komunikaty muszą być podpisane przez MUA lub MTA (w tym
wypadku M oznacza raczej Messaging, niż Mail) - tak aby dało się
jednoznacznie określić nadawcę i uwierzytelnić treść komunikatu),
a wszystkie wiadomości kodowane w sposób transparentny dla MTA nadawcy
i MUA odbiorcy, ale nie dla pośredników (nie posiadających odpowiednich
kluczy),
1) wszystkie wiadomości od użytkownika są zakodowane kluczem jednorazowym
i podpisane jego kluczem prywatnym, a następnie deponowane do odbioru
na serwerze obsługującym danego użytkownika,
2) klucz publiczny każdego użytkownika jest zdeponowany na wszystkich
obsługujących go serwerach i udostępniany serwerom obsługującym nadawców,
którzy otrzymali zgodę na wysyłanie wiadomości do danego użytkownika,
3) adresaci wiadomości otrzymują powiadomienie, że na określonym serwerze
obsługującym użytkownika znajduje się dla nich wiadomość - oraz klucz
jednorazowy do tej wiadomości, zakodowany ich kluczem publicznym przez
serwer obsługujacy nadawcę,
4) wiadomości wychodzące z serwera zostają podpisane kluczem prywatnym
serwera, klucz publiczny serwera mają wszystkie serwery, wymieniające
z nim wiadomości, każdy serwer wymienia pocztę tylko z określonymi
serwerami, więc tym samym każda wiadomość przechodzi przez pewną ilość
serwerów, z których każdy "zna" poprzednika, przekazujacego tę wiadomość,
5) odpowiedni routing od nadawcy do odbiorcy zapewnia nam system
zbliżony do DNS,
6) nadużycia w ruchu między serwerami - wpuszczanie nieautoryzowanego
ruchu, próby włamań, kradzieży kluczy itp. - skutkowałyby natychmiastowym
odcięciem serwera od sieci usług,
7) adresat prócz informacji o istnieniu przesyłki może otrzymać prośbę
o zgodę na przyjmowanie przesyłek (w przypadku akceptacji serwer odbiorcy
wysyła klucz publiczny odbiorcy do serwera nadawcy), komunikat o odmowie
przyjmowania przesyłek od któegoś z odbiorców lub ew. kopię skargi do
administratora i odpowiedzi na skargę - o czym niżej,
8) cały proces jest całkowicie przezroczysty dla użytkownika - nie musi
on nic wiedzieć o kluczach, podpisywaniu wiadomości itd. - cały proces
przebiega automatycznie; klucz prywatny jest generowany przez i powiązany
z MUA użytkownika, podobnie klucze jednorazowe do kodowania poszczególnych
przesyłek, a klucze publiczne krążą wyłacznie między serwerami,
9) użytkownik musi przy zakładaniu konta poświecić albo sporo czasu, albo
trochę pieniędzy na założenie konta przez operatora komercyjnego) - wazne,
aby proces zakładania nowego konta był albo czasochłonny, albo kosztowny.

Powyższe założenia mają na celu pełne uwierzytelnienie tożsamości nadawców,
odbiorców i serwerów.

Jeśli ten problem bedziemy mieli rozwiazany, to możemy pójść w stronę
obciążania użytkowników i pośredników za działania niepożądane.

Ważne, aby w każdym momencie mieć pewność, że obciążenia ponosi właściwa
osoba. Odpowiedzialność i wiarygodność użytkowników i serwerów można by
wówczas oprzeć o system punktowy, jak w przypadku użytkowników serwisów
aukcyjnych.

Użytkownicy i administratorzy mieliby określone konta punktowe. Punkty
ujemne byłyby przydzielone użytkownikom za próby nadużyć lub fałszywe
zgłoszenia nadużyć, a dodatnie - za zgłoszenia potwierdzone. Natomiast
administratorzy uzyskiwaliby punkty ujemne za nieprawidłowe rozpatrzenie
zgłoszenia, dodatnie - za prawidłowe. Nadużycia ze strony administratorów
skutkowałyby natomiast natychmiastowym odcięciem ich serwera.

Chodzi o to, aby system był jak najbardziej zautomatyzowany, aby jak najmniej
absorbował administratorów - ale żeby można się było skutecznie odwoływać
w przypadku fałszywych posądzeń. Dlatego nie tylko kara za nadużycia, ale
i kara za bezpodstawne wszczynanie procedur odwoławczych musiałaby być
dotkliwa.

(Poniżej przykład i na końcu jeszcze komentarz.)

*********************

Przykładowo, możliwy rozwój sytuacji w przypadku otrzymania spamu lub próby
wyłudzenia wyglądałby następująco:

Użytkownik mógłby w każdej chwili odwołać swoją zgodę na odbiór przesyłek
od danego nadawcy. Przy czym w odpowiednim formularzu byłoby jednocześnie
przewidziane miejsce na opcjonalne podanie powodu odmowy - można sobie
wyobrazić pewną listę powodów (np. przeprowadzka, rezygnacja z działalności
gospodarczej, brak zainteresowania ofertą nadawcy) zależnych od odbiorcy
lub od nadawcy. W tym drugim przypadku można by wymienić m.in. różne
kategorie nadużyć - rozsyłanie spamu, reklamę towaru/usługi niezgodną
ze stanem faktycznym, próbę wyłudzenia, przesyłanie spamu jako prośby
o zgodę na korespondencję itd.

Gdyby pewna liczba odbiorców zaznaczyła tę samą kategorię w odniesieniu
do tego samego nadawcy w ciągu niezbyt długiego czasu - np. 5 w ciagu doby
- nadawca byłby automatycznie blokowany na określony czas, np. na dwa dni.
Przy następnym takim przypadku, okres blokady wydłużałby się np. dwukrotnie.
Jednocześnie ten sam nadawca nie mógłby zarejestrować w okresie blokady
nowego konta - co najmniej u tego samego dostawcy, a najlepiej - w ogóle.
Jeśli założyć, że każdy MUA musiałby podpisywać/kodować automatycznie
wiadomości kluczem prywatnym użytkownika, to byłaby po prostu blokada
przyjmowania przesyłek oraz próśb o założenie konta podpisanych/zakodowanych
tym kluczem.

Oczywiście, nadawca miałby prawo się odwołać do administratora serwera.
Administrator badałby problem i ewentualnie odblokowywał konto w przypadku
nieuzasadnionej skargi (mało prawdopodobne, żeby kilka osób naraz przypadkiem
uznało wysyłkę za spam lub próbę wyłudzenia, no ale może się zdarzyć,
że to osoby podstawione przez konkurenta). Jeśli skarga będzie zdaniem
administratora nieuzasadniona, powinien poinformować odbiorcę, który się
skarżył, oraz administratora jego serwera.

Użytkownik, który zgłosił nadużycie (czyli gdyby administrator serwera
nadawcy potwierdził, że to nadużycie), otrzymywałby punkt dodatni.
W przypadku fałszywego alarmu - zgłaszający otrzymywałby automatycznie
punkt ujemny, ale mógłby się z kolei odwołać - do swojego administratora.
Ten mógłby uznać, że punkt ujemny się należy, lub nie. Oczywiście, obaj
administratorzy mieliby kopie przesłanych wiadomości i zgłoszeń, więc
powinni mieć pełną orientację w temacie.

System punktów wspomagałby automatyzację procedur na zasadzie przypisywania
zgłoszeniom wagi zależnej od wiarygodności zgłaszajacego: użytkownicy,
mający na koncie zbyt wiele punktów ujemnych (fałszywych alarmów), byliby
niewiarygodni - ich zgłoszenia nie powodowałyby blokady konta nadawcy.
Użytkownicy bez żadnej historii - mieliby niewielką wiarygodność
- potrzeba by było wielu ich zgłoszeń, żeby konto nadawcy zostało
zablokowane. Natomiast użytkownicy, raportujący wyłacznie lub prawie
wyłacznie faktyczne nadużycia, byliby traktowani jako wiarygodni,
a na ich zgłoszenia system reagowałby natychmiastową blokadą nadawcy.

Podobny system punktowy obowiązywałby administratorów. Przy czym brak
wiarygodności skutkowałby nieprzyjmowaniem wiadomości od danego serwera
przez serwery wymieniające z nim ruch. Oczywiście, wiarygodność mierzona
w punktach dotyczyłaby rozpatrywania zgłoszeń nadużyć popełnianych przez
użytkowników danego serwera (oceniającym byłby tu administrator
serwera odbiorcy; oceniałby sposób rozpatrzenia skargi odbiorcy przez
administratora serwera nadawcy, na wniosek odbiorcy - składany oczywiście
po negatywnym rozpatrzeniu skargi).

W przypadku, gdy administrator serwera nadawcy odrzuciłby skargę prawidłowo,
dostawałby punkt dodatni. Gdyby pomyliłby się w ocenie sytuacji,
otrzymywałby punkt ujemny, ale wówczas mógłby z olei poprosić o arbitraż.
Nadmierna ilość punktów ujemnych administratora (czyli sprzyjanie
użytkownikom wbrew stanowi faktycznemu, potwierdzanemu przez innych
administratorów) skutkowałaby zablokowaniem serwera (wymiany wiadomości
z tym serwerem). Również na określony czas i również z wydłużaniem tego
okresu w razie recydywy.

Ostateczną instancją odwoławczą (w przypadku, gdyby administrator serwera
odbiorcy nie zgodził się z odrzuceniem skargi odbiorcy przez administratora
serwera nadawcy) byłby arbitraż, na wniosek administratora serwera nadawcy.

W przypadku arbitrażu, arbitrami mogliby być wyłacznie administratorzy
z dodatnim kontem. Z tym że arbitraż rozstrzygnięty na niekorzyść
administratora powodowałby dodanie mu dużo większej liczby punktów
ujemnych lub blokadę serwera - tak, aby dotkliwie karać niezgodne ze stanem
faktycznym odrzucanie skarg (przez administratora nadawcy) lub pieniactwo
(administratora odbiorcy). Przy czym blokadą serwera byłaby tak naprawdę
odmowa przyjmowania jakichkolwiek wiadomości z niego wychodzących. Tego
każdy administrator będzie wolał uniknąć.

************************

Dlaczego tak? Otóż, klasyczne metody (składanie doniesień na policji/w
prokuraturze, oczekiwanie na reakcję organów ścigania, a później na proces,
oraz rozstrzygnięcia sądowe) są długotrwałe. W przypadku nadużyć internetowych
trzeba reagować praktycznie natychmiast. Powyższa procedura daje wszystkim
zainteresowanym możliwość dochodzenia swoich praw, gwarantuje możliwość
odwołania na każdym etapie i umożliwia ukaranie winnego w sposób, który będzie
dla niego w danej sytuacji dotkliwy. Z drugiej strony, taki system pozwala
wprawdzie uzyskać szybkie rozgrzeszenie, ale kara w przypadku recydywy jest
bardziej dotkliwa.

Poza tym, cała ta procedura nie angażuje w żaden sposób istniejacego
prawa, ale też nie wyłacza w żaden sposób istniejacej drogi prawnej.
Jeśli administratorzy i użytkownicy akceptując regulamin usług zgadzaliby
się na taki sposób rozwiazywania sporów, to powyższe procedury gwarantują
szybkie i dotkliwe ukaranie sprawcy, ale jednocześnie kara jest karą
regulaminową i o ile tylko regulamin zostanie sformułowany prawidłowo
(przydałby się w tym celu prawnik), a wszystkie punkty procedury zostaną
również prawidłowo przeprowadzone, to decyzja o blokadzie danego użytkownika
czy serwera będzie nie do podważenia przez sądy. W ten sposób będziemy mieli
narzędzie do skutecznego zaprowadzania porządku w sieci.

Taki system może w początkowej fazie istnieć obok bardziej tradycyjnych
usług (SMTP, IM). Jeśli będzie dla użytkowników wygodny, przezroczysty,
elastyczny, szybko je wyprze. Ale na początku będzie tylko dodatkiem
- dopiero, gdy znajdzie się odpowiednio dużo użytkowników, skłonnych
z niego korzystać, zacznie być implementowany przez firmy komercyjne.
Dlatego pierwsze konto każdy potencjalny użytkownik powinien móc dostać
minimalnym nakładem sił i kosztów - na zachętę.

--
Godryk :: Tomek Marcinkowski :: http://godric.sf-f.pl
______________________________________________________________

>>> [ Daj mi agrafkę! Żywcem mnie nie wezmą! ] <<<

Piotr KUCHARSKI

unread,
Jun 13, 2006, 5:44:23 PM6/13/06
to
Godryk <god...@sf-f.pl> wrote:
> Przede wszystkim: OIDP wirusy nie korzystają z MUA, a tylko z ksiażki
> adresowej. Wiec można by było dodać autoryzację każdego MUA przy wysyłce
> - choćby klucz prywatny do podpisywania wiadomości, przechowywany na dysku,
> ale chroniony hasłem, które użytkownik musi wpisać przy każdym odpaleniu
> MUA.

...i checkbox "zapamiętaj hasło".

p.

--
Wylistować w RBL-u wszystkich! MTA rozpozna swoich.

Paweł Kierski

unread,
Jun 14, 2006, 2:52:14 AM6/14/06
to
Godryk w wiadomości <slrne8tne0...@godric.was.here> pisze:

> Sergiusz Rozanski pisze:
> > Dnia 13.06.2006 Godryk <god...@sf-f.pl> napisał/a:
> >>
> >> Mam pewien pomysł idący w tym kierunku, mogę go przedstawić, jesli chcecie.
> >
> > O tak, dawaj, narazie każdy pomysł się liczy.
>
> Na razie myślę tak: protokół powinien być modularny i umożliwiać
> różne implementacje sposobu autoryzacji lub "opłaty" za dotarcie
> do odbiorcy. Czy przy każdym kontakcie, czy tylko przy pierwszym,
> czy "drożej", czy "taniej" - to wszystko są szczegóły, które
> docelowo powinien ustawiać użytkownik, znaczy - potencjalny odbiorca.

O! Kolejna osoba zaczyna chwytać 8-)

> Problem w tym, że samo ustawianie będzie pracochłonne. Trzeba więc
> będzie ustawić jakieś defaultowe wartości, które pewnie będą
> wykorzystane przez 95% użytkowników.
>
> Poza tym, sama złożoność różnych technik - choćby zadawania zagadek
> (obrazek, tekst, dźwięk) spowoduje, że implementacja będzie skomplikowana.

"Od tego jest małpa, żeby liczyć" - implementacja dobrego projektu
nie jest problemem. Ważne, żeby pułapki starać się wychwytywać i
eliminiować na etapie projektu właśnie.

> Zacząłem sie więc zastanawiać nad "wbudowaniem w protokół" odpowiedzialności
> użytkowników i administratorów.

Tak, ale...
Jakoś ostanio przywiązałem się do zasady, że sądzi się osobę, ale za
czyny. Dlatego uważam, że obowiązkowa identyfikacja podmiotu nie jest
dobrym pomysłem. Identyfikacja może być jednym z elementów autoryzacji
(secyficzną formą "opłaty" lub częścią "opłaty"), ale twardo będę stał
na stanowisku, że kategoria anonimowego nadawcy powinna zostać.
Wolałbym takie podejście - anonimowy nadawca jest na tyle
ograniczony w protokole, że nie ma jak nadużyć protokołu, ewentualnie
nadużycia są spowodowane przez wyjątkowo niefrasobliwą konfigurację po
stronie odbiorcy.
Oczywiście pełnej anonimowości nie ma - i to może nawet lepiej 8-)
Ale chodzi o zabezpieczenie anonimowości na takim poziomie, że jeśli
nie chcę się przedstawić, to nie muszę, ale wysłać komunikat mogę (być
może tylko będzie to wymagało sporego zaangażowania środków), a żeby
mnie zidentyfikować jako nadawcę potrzeba dużo większych środków i
uprawnień.

Sergiusz Rozanski

unread,
Jun 14, 2006, 6:52:42 AM6/14/06
to
Dnia 13.06.2006 Piotr KUCHARSKI <cho...@sgh.waw.pl> napisał/a:
> Godryk <god...@sf-f.pl> wrote:
>> Przede wszystkim: OIDP wirusy nie korzystają z MUA, a tylko z ksiażki
>> adresowej. Wiec można by było dodać autoryzację każdego MUA przy wysyłce
>> - choćby klucz prywatny do podpisywania wiadomości, przechowywany na dysku,
>> ale chroniony hasłem, które użytkownik musi wpisać przy każdym odpaleniu
>> MUA.
>
> ...i checkbox "zapamiętaj hasło".

Dziwne że wirusy i zombie jeszcze tego nie używają, miałyby otwarte
relaye przez mta użytkownika, ale to też z 2 strony dawałoby poddatnośc
na szybkie namierzenie infekcji, pewnie z tego powodu autorzy tych
programów nie używają tego.

Marcin Kulas

unread,
Jun 14, 2006, 6:58:57 AM6/14/06
to
Sergiusz Rozanski wrote:
> Dnia 13.06.2006 Piotr KUCHARSKI <cho...@sgh.waw.pl> napisał/a:
> > ...i checkbox "zapamiętaj hasło".
>
> Dziwne że wirusy i zombie jeszcze tego nie używają, miałyby otwarte
> relaye przez mta użytkownika, ale to też z 2 strony dawałoby poddatnośc
> na szybkie namierzenie infekcji, pewnie z tego powodu autorzy tych
> programów nie używają tego.

Używają. Niedawno leciał mi spam przez serwer z uwierzytelnionego klienta.
Jak się okazało, ich komputer złapał syfa i siał wykorzystując jego login
i hasło.

wer

unread,
Jun 14, 2006, 2:49:13 PM6/14/06
to
Czytam, czytam watek i widze coraz bardziej zakrecone pomysly:

1. Klucz prywatny i publiczny.

Wszystko fajnie, ale... Wiele osob korzysta z jednego konta w wielu
miejscach, w pracy, w domu, przez webmail. W kazdym tym miejscu musi byc
wtedy umieszczony klucz prywatny. Biorac pod uwage jak zaawansowani sa
uzytkownicy to bedzie caly czas problem. Poza tym wirus/trojan moze
przechwycic taki klucz. Udreka bedzie zmiana klucza. Zmiana nie tylko na
komputerze, ale potem zmiana kluczy publicznych. Spowoduje to wiecej
tyle zamieszania. Wiekszosc uzytkownikow ma problemy z zapamietaniem,
gdzie nalezy kliknac, zeby wyslac mail. Taka jest prawda. Zarzadzanie
swoim kluczem prywatnym przekroczy ich percepcje. Jesli przechowywac
klucze na jakims serwerze, to serwer automatycznie bedzie bardziej
narazony na ataki.

A co jak ktos ma 3 konta pocztowe (przypadek czesty). Dla kazdego konta
osobny klucz?

2. Oplata za wyslanie

a - moc obliczeniowa, musi byc sprawiedliwie, ten kto ma Opteron 280
Dual Core powinien rozwiazywac zagadke tyle co ten co ma Durona 1000.
Tylko zaraz pojawi sie soft, symulujacy, ze mamy slabszy procesor. Jesli
zadanie bedzie niezalezne od mocy procesora, to wtedy bogatsi sa
uprzywilejowani. Ich komputer znacznie szybciej wysle mail.

b - zagadki obrazkowe - wycinamy wszystkich korzystajacych z poczty
przez ssh.

c - slowne - duze wykorzystanie sieci, nie kazdy ma karte dzwiekowa,
szczegolnie w biurach.

d - zagadki tekstowe - znajomosc jezykow obcych, nie kazdy musi znac
jezyk obcy dobrze, a moze sie kontaktowac z zagranica. Jakis arab
umiesci swoja zagadke po arabsku to dowidzenia.

e - mikroplatnosci - no coz, pisze wirusa, ktory bedzie wysylal do mnie
od usera jednego maila miesiecznie. 1 mln kopii wirusa, 1 mail to 1
cent. W zasadzie moge lezec i ogladac sufit, a kasa plynie. A w razie
zlapania mam niska spoleczna szkodliwosc czynu, 1 cent to zaden pieniadz.

A co z rozsylka informacji o wygasaniu uslug albo z podobnymi
informacjami? Mam wydawac grube tysiace na sprzet, obsluge, platnosci za
maile z informacjami do klientow?

------------------------------------------------------------------------

Nowy protokol pocztowy musi byc maksymalnie o ile to mozliwe oparty na
obecnym, z kilku wzgledow:

1. Calkiem nowy i SKOMPLIKOWANY soft to setki nowych dziur. Przez
pierwsze dwa lata bedzie tylko latanie bugow.

2. Astronomiczne koszty wdrozenia.

3. Zmiana przyzwyczajen userow, co jest najtrudniejsze.


Mozna w obecnym protokole zmniejszyc spam i to znacznie, wystarcza 4 zmiany:

a. Rozdzielenie portow do komunikacji miedzyserwerowej i klient -
server. Latwo wtedy na firewallu ustawic, ze klient ma lub nie ma prawa
do wysylania przez port miedzyserwerowy. Zlikwiduje to wiekszosc zombie
i wirusow.

b. Serwer pocztowy musi miec rev-dns zaczynajacy sie od okreslonego
zestawu znakow. Odwalamy na dzien dobry wszystkie serwery bez tego. Moze
byc np poczatek mta-xx.domena, gdzie xx to numer.

c. Ograniczenie wysylki maili domyslnie na kazdym koncie do 30 na
godzine. W przypadku uzasadnionym limit moze byc zwiekszony.

d. Oplata, nawet symboliczna za zalozenie darmowego konta pocztowego. 3
zl sms-em nie jest majatkiem, ale dla osob zakladajacych setki kont juz
staje sie dokuczliwa.

Przy takich zmianach nasilenie spamu znacznie zmaleje. Sieci wspierajace
spamerow zostana wyciete, bo latwo bedzie mozna odroznic spam support,
od nieradzenia sobie z siecia. Przy takich zmianach provider bedzie
swiadomie musial wspierac spamera, zmieniajac mu rev-dns, otwierajac
wyjscie na port 25. Takich sieci nie bedzie duzo i raczej polegna. W
sumie zamiast rbl, bedzie lista AS do blokowania na firewallu/tablicy
routingu, mniej obciazajaca system od rbl-a.

Nie wprowadzamy zadnych nowych rzeczy tak naprawde. Nie trzeba zmieniac
oprogramowania. Wystarczy przekonfigurowac co nieco i tyle. Baza
serwerow mailowych jest rozproszona i nie mozna jej zaatakowac w latwy
sposob. Odpowiednie organizacje RIPE/ARIN/APNIC moga miec wglad w to co
sie dzieje i np odbierac AS dla providerow wspierajacych spamerow.


wer

Sergiusz Rozanski

unread,
Jun 14, 2006, 5:25:06 PM6/14/06
to
Dnia 14.06.2006 wer <arx...@o2.pl> napisał/a:
> Czytam, czytam watek i widze coraz bardziej zakrecone pomysly:
>
> 1. Klucz prywatny i publiczny.

> Wszystko fajnie, ale... Wiele osob korzysta z jednego konta w wielu
> miejscach, w pracy, w domu, przez webmail. W kazdym tym miejscu musi byc

też uważam że nie najlepszy pomysł ze względu na dystrybucje.

> 2. Oplata za wyslanie
>
> a - moc obliczeniowa, musi byc sprawiedliwie, ten kto ma Opteron 280
> Dual Core powinien rozwiazywac zagadke tyle co ten co ma Durona 1000.
> Tylko zaraz pojawi sie soft, symulujacy, ze mamy slabszy procesor. Jesli
> zadanie bedzie niezalezne od mocy procesora, to wtedy bogatsi sa
> uprzywilejowani. Ich komputer znacznie szybciej wysle mail.

pozatym klastry zombie :)

> b - zagadki obrazkowe - wycinamy wszystkich korzystajacych z poczty
> przez ssh.

bez przesady, nawet łącząc się przez ssh w dzisiejszych czasach robisz
to na konsoli mającej choćby primytywne możliwości graficzne, kwestia
chęci.

> c - slowne - duze wykorzystanie sieci, nie kazdy ma karte dzwiekowa,
> szczegolnie w biurach.

jak duże? dźwięk nei musi być w jakości cd-audio, drugi warunek -zgoda.

> d - zagadki tekstowe - znajomosc jezykow obcych, nie kazdy musi znac
> jezyk obcy dobrze, a moze sie kontaktowac z zagranica. Jakis arab
> umiesci swoja zagadke po arabsku to dowidzenia.

jakoś nie umiem sobie wyobrazić dialogu między osobami nie znającymi
wspolnego języka, naciąganie.

> e - mikroplatnosci - no coz, pisze wirusa, ktory bedzie wysylal do mnie
> od usera jednego maila miesiecznie. 1 mln kopii wirusa, 1 mail to 1
> cent. W zasadzie moge lezec i ogladac sufit, a kasa plynie. A w razie
> zlapania mam niska spoleczna szkodliwosc czynu, 1 cent to zaden pieniadz.

propozycja była nie za maila a za dostęp do danych odbiorcy, więc nawet
słac nie musisz, pytanie tylko czego wymagać będzie dostęp do uregulowania
tych miktopłatności i czy Twój zombie je spełni, równie dobrze obecnie
możesz napisac wirusa który u wielu userów zrobi zakupy w Twoim sklepie
więc - naciąganie.

> A co z rozsylka informacji o wygasaniu uslug albo z podobnymi
> informacjami? Mam wydawac grube tysiace na sprzet, obsluge, platnosci za
> maile z informacjami do klientow?

no chyba z dostępem do skrzynek na własnych maszynach nie masz problemów,
to już bardzo naciągane.

> ------------------------------------------------------------------------
>
> Nowy protokol pocztowy musi byc maksymalnie o ile to mozliwe oparty na
> obecnym, z kilku wzgledow:
>
> 1. Calkiem nowy i SKOMPLIKOWANY soft to setki nowych dziur. Przez
> pierwsze dwa lata bedzie tylko latanie bugow.

nie odrazu Kraków...

> 2. Astronomiczne koszty wdrozenia.

ale czy nie mniejsze niż nakłady na walkę ze spamem? może kożystniej
jest przezucić te środki na coś nowego, niż łatać niereformowalne smtp?

> 3. Zmiana przyzwyczajen userow, co jest najtrudniejsze.

Masz na myśli "głód spamu" :D objawy moga wystąpić heh

> Mozna w obecnym protokole zmniejszyc spam i to znacznie, wystarcza 4 zmiany:
>
> a. Rozdzielenie portow do komunikacji miedzyserwerowej i klient -
> server. Latwo wtedy na firewallu ustawic, ze klient ma lub nie ma prawa
> do wysylania przez port miedzyserwerowy. Zlikwiduje to wiekszosc zombie
> i wirusow.

widzę tendencje w tą stronę zmierzającą, również popularność ssl+sasl rośnie,
również popieram takie zmiany.

> b. Serwer pocztowy musi miec rev-dns zaczynajacy sie od okreslonego
> zestawu znakow. Odwalamy na dzien dobry wszystkie serwery bez tego. Moze
> byc np poczatek mta-xx.domena, gdzie xx to numer.

wchodzimy na obce podwórko, nie tędy droga, właściwy smtp jest zaznaczany
już w dns przez spf, tu już są zarzuty agresywnego wejścia w dns (chodzi o
txt), sądzę że wymagany specyficzny rev-dns byłby tak samo krytykowany,
pozatym nie każdy ma możliwość zmiany rev-dns, zwróć uwagę na kompetencje
sieciowca i postmastera, to w wielu przypadkach 2 różne ogródki.

> c. Ograniczenie wysylki maili domyslnie na kazdym koncie do 30 na
> godzine. W przypadku uzasadnionym limit moze byc zwiekszony.

na free kontach tak, to powinno być obowiązkowe.

> d. Oplata, nawet symboliczna za zalozenie darmowego konta pocztowego. 3
> zl sms-em nie jest majatkiem, ale dla osob zakladajacych setki kont juz
> staje sie dokuczliwa.

to fakt, ale na gmail jest za free więc?


Nie uważam też że jakaś organizacja ma mi coś kontorolować itp,
protokół dostępu do danych powinien być przezemnie kontrolowany i na
moją odpowiedzialność.
Właściwie pomysł z dystrybucją danych jest na tyle fajny że mógłbym
pozostać przy smtp ;) a zmieniać adres np co tydzień, korzystając
z elementów typu delimiter, nie byłoby to aż tak trudne, a przy zwiększeniu
poziomu spamu mógłbym sobie zrobić 'nowe' konto i je wpisać dla kontaktów.

Piotr Suchowski

unread,
Jun 14, 2006, 6:13:53 PM6/14/06
to
Paweł Kierski napisał(a):
> Takie moje przemyślenia z kilku postów, w których już zaczęło się
> prawie projektowanie protokołu... 8-)
> (....)

A nie lepiej nakazać signowania pgp ? Wszystko co nie ma siga leci do
/dev/null, wszystko co jest sygnowane keyem spamera, czy innego
degenerata leci do /dev/null
Wystarczy rozproszona siec serwerów public key bez możliwości dublowania
kluczy... chyba :)

Tak, to utopia :-)

--
,,,
(o o)
========================oOO==(_)==OOo=========================
irc: for...@irc.gisz.com Piotr Suchowski
jid: for...@chrome.pl .oooO Oooo. http://sernik.org
========================(''')==(''')==========================
pgp id: 0x433F327C \ ( ) /
\_) (_/

Marcin Stępnicki

unread,
Jun 14, 2006, 6:26:36 PM6/14/06
to
Dnia Wed, 14 Jun 2006 21:25:06 +0000, Sergiusz Rozanski napisał(a):

> jakoś nie umiem sobie wyobrazić dialogu między osobami nie znającymi
> wspolnego języka, naciąganie.

Mały sprzeciw chociaż może nie do końca związany z tematem. Kilkakrotnie
zdarzyło mi się pisać po angielsku do kogoś kto odpisywał mi po
hiszpańsku (i odwrotnie), a raz dogadać z Włochem dzięki Babelfishowi
(on ani w ząb po angielsku, ja zero po włosku).

Ale i tak pomysł z zagadkami mi się nie podoba, za dużo z tym wszystkim
zachodu - Wer ma 99% racji. Nie ma szans zrobić rewolucyjnych zmian, a
poza tym w przeciwieństwie do chyba większości Grupowiczów nie uważam
żeby ESMTP był sam w sobie złym protokołem - wymaga po prostu
różnych "pluginów". Skoro przez tyle lat wygodniej było dodać
kolejną funkcjonalność niż wyrzucić całość do kosza dowodzi też w
jakiś sposób jego elastyczności i zachowania bardzo ważnej cechy -
"łagodnej degradacji". Z wielu rozszerzeń _można_, ale nie _trzeba_
korzystać, kolejne poziomy zwiększają po prostu wiarygodność nadawcy
i raczej wolałbym dążyć do ich większego upowszechnienia i
ograniczenia problemu zombie, który tak naprawdę jest kluczowy - spam to
w tym ujęciu skutek, a nie przyczyna problemu.

--
| And Do What You Will be the challenge | http://apcoln.linuxpl.org
| So be it in love that harms none | http://biznes.linux.pl
| For this is the only commandment. | http://www.juanperon.info
`---* JID: Aragor...@jabber.org *---' http://www.naszedzieci.org

Marcin Stępnicki

unread,
Jun 14, 2006, 6:28:43 PM6/14/06
to
Dnia Thu, 15 Jun 2006 00:13:53 +0200, Piotr Suchowski napisał(a):

> A nie lepiej nakazać signowania pgp ? Wszystko co nie ma siga leci do
> /dev/null, wszystko co jest sygnowane keyem spamera, czy innego
> degenerata leci do /dev/null

Na początku zbyt radykalne, ale niski limit punktacji powyżej
której uznajemy wiadomość za spam i ujemny score dla listów z podpisem
to moim zdaniem dobry pomysł.

wer

unread,
Jun 14, 2006, 7:35:12 PM6/14/06
to
Sergiusz Rozanski wrote:
>>d - zagadki tekstowe - znajomosc jezykow obcych, nie kazdy musi znac
>>jezyk obcy dobrze, a moze sie kontaktowac z zagranica. Jakis arab
>>umiesci swoja zagadke po arabsku to dowidzenia.
>
>
> jakoś nie umiem sobie wyobrazić dialogu między osobami nie znającymi
> wspolnego języka, naciąganie.

Ktos pisze do niemca pytanie:

I see on your website product. I want more information about this. I na
tym konczy sie co napisze. A dostaje zagadke:

Viewiel ist zwei und drei.

I co wtedy, nie zna niemieckiego. A zagadki po angielsku tez nie rozumie.

>
>>A co z rozsylka informacji o wygasaniu uslug albo z podobnymi
>>informacjami? Mam wydawac grube tysiace na sprzet, obsluge, platnosci za
>>maile z informacjami do klientow?
>
>
> no chyba z dostępem do skrzynek na własnych maszynach nie masz problemów,
> to już bardzo naciągane.

Nie bardzo. Mam sporo domen, ktore sa na innych serwerach. Rejestrujemy
domeny, ale dla nich nie zapewniamy serwera.

>>
>>Nowy protokol pocztowy musi byc maksymalnie o ile to mozliwe oparty na
>>obecnym, z kilku wzgledow:
>>
>>1. Calkiem nowy i SKOMPLIKOWANY soft to setki nowych dziur. Przez
>>pierwsze dwa lata bedzie tylko latanie bugow.
>
>
> nie odrazu Kraków...
>

Tak, tylko ze tutaj od razu bedzie najazd hord tatarskich. Nie bedzie
czekania.

>
>>2. Astronomiczne koszty wdrozenia.
>
> ale czy nie mniejsze niż nakłady na walkę ze spamem? może kożystniej
> jest przezucić te środki na coś nowego, niż łatać niereformowalne smtp?
>

Obawiam sie, ze bedzie wyzszy i dlugotrwaly.

>
>>3. Zmiana przyzwyczajen userow, co jest najtrudniejsze.
>
> Masz na myśli "głód spamu" :D objawy moga wystąpić heh

User przyzwyczajony do jednej rzeczy potraktuje zmiane jak zamach na
wolnosc osobista.


>>b. Serwer pocztowy musi miec rev-dns zaczynajacy sie od okreslonego
>>zestawu znakow. Odwalamy na dzien dobry wszystkie serwery bez tego. Moze
>>byc np poczatek mta-xx.domena, gdzie xx to numer.
>
>
> wchodzimy na obce podwórko, nie tędy droga, właściwy smtp jest zaznaczany
> już w dns przez spf, tu już są zarzuty agresywnego wejścia w dns (chodzi o
> txt), sądzę że wymagany specyficzny rev-dns byłby tak samo krytykowany,

Wcale nie obce. A poza tym jesli ktos ma stale IP i stawia serwer to
moze wystapic o zmiane rev, bo ten adres jest dla niego. Jakos nigdzie
nie mialem z tym problemu.

>
>>c. Ograniczenie wysylki maili domyslnie na kazdym koncie do 30 na
>>godzine. W przypadku uzasadnionym limit moze byc zwiekszony.
>
> na free kontach tak, to powinno być obowiązkowe.

Nie tylko na free. Raczej nikt nie odpisuje na maile z predkoscia 1 na
minute.

>
>>d. Oplata, nawet symboliczna za zalozenie darmowego konta pocztowego. 3
>>zl sms-em nie jest majatkiem, ale dla osob zakladajacych setki kont juz
>>staje sie dokuczliwa.
>
>
> to fakt, ale na gmail jest za free więc?

To wymaga zmian u wszystkich dostawcow darmowych kont. Niestety to jest bol.

wer

Sergiusz Rozanski

unread,
Jun 15, 2006, 5:22:05 AM6/15/06
to
Dnia 14.06.2006 wer <arx...@o2.pl> napisał/a:
>>
>> to fakt, ale na gmail jest za free więc?
>
> To wymaga zmian u wszystkich dostawcow darmowych kont. Niestety to jest bol.

Też mi się wydawało że sa niereformowali, ale zwróć uwagę że np spf
mają wszyscy, więc nie jest tak że nie przyjmują nowości, tu jednak
ten kto zacznie pobierać opłaty to straci najwięcej :)

Bardzo spodobał mi się pomysł chowania adresu i wogóle danych, bo nie wymaga
zmian w samych protokołach, tylko użycia nowego jakby nadrzędnego,
przenośnego protokołu do znalezienia osoby i to jest chyba to i nad tym
powinniśmy się skupić, bo nie ingerujemy bezpośrednio w niczyje podwórko.

Robert Rędziak (prawdziwego adresu szukaj w sygnaturce)

unread,
Jun 15, 2006, 7:19:48 AM6/15/06
to
On Wed, 14 Jun 2006 21:25:06 +0000 (UTC), Sergiusz Rozanski
<write-onl...@sergiusz.com> wrote:

> jakoś nie umiem sobie wyobrazić dialogu między osobami nie znającymi
> wspolnego języka, naciąganie.

Swego czasu jeden mój znajomy napalił się Skyline GT-R. Chciał
go ciągać z .jp, bo tak taniej i tam mają najfajniejsze zabawki.
Zgadnij, jak się odbywałą komunikacja między nim, a Małymi
Żółtymi (i dlaczego to wyglądało jak babelfish)?

>> 3. Zmiana przyzwyczajen userow, co jest najtrudniejsze.
>
> Masz na myśli "głód spamu" :D objawy moga wystąpić heh

Najwyraźniej nie masz do czynienia ze zwykłymi (powtarzam,
zwykłymi) użytkownikami. Tymi, którzy dzwonią do helldesku,
bo im wcięło ikonkę od eksplorera.

r.
--
_________________________________________________________________
robert rędziak mailto:spambox-at-supersonic-dot-plukwa-dot-net
klubsubaru.pl uratuj stratopoloneza: http://www.stratopolonez.pl
List otwarty przeciwko DRM: http://list.7thguard.net/

Marcin Stępnicki

unread,
Jun 15, 2006, 7:21:22 AM6/15/06
to
Dnia Thu, 15 Jun 2006 11:19:48 +0000, Robert Rędziak napisał(a):

> Najwyraźniej nie masz do czynienia ze zwykłymi (powtarzam,
> zwykłymi) użytkownikami. Tymi, którzy dzwonią do helldesku,
> bo im wcięło ikonkę od eksplorera.

... i mówią, że przepraszają że dzwonią ale właśnie skasowali internet.

wer

unread,
Jun 15, 2006, 11:21:26 AM6/15/06
to
Marcin Stępnicki wrote:
> Dnia Thu, 15 Jun 2006 11:19:48 +0000, Robert Rędziak napisał(a):
>
>
>> Najwyraźniej nie masz do czynienia ze zwykłymi (powtarzam,
>> zwykłymi) użytkownikami. Tymi, którzy dzwonią do helldesku,
>> bo im wcięło ikonkę od eksplorera.
>
>
> ... i mówią, że przepraszają że dzwonią ale właśnie skasowali internet.
>

A potem dzwoni ich administrator sieci, z glosu ma 15 lat i mowi, ze
poczta nie chodzi, bo nie moga sie polaczyc nigdzie.

wer

Sergiusz Rozanski

unread,
Jun 15, 2006, 1:52:44 PM6/15/06
to
Dnia 15.06.2006 Robert Rędziak <spam_go...@supersonic.plukwa.net> napisał/a:

>>> 3. Zmiana przyzwyczajen userow, co jest najtrudniejsze.
>>
>> Masz na myśli "głód spamu" :D objawy moga wystąpić heh
>
> Najwyraźniej nie masz do czynienia ze zwykłymi (powtarzam,
> zwykłymi) użytkownikami. Tymi, którzy dzwonią do helldesku,
> bo im wcięło ikonkę od eksplorera.

Tacy się uczą i tak na pamięć sekwencji wysłania poczty czy wchodzenia na
wp. Co dla nich za różnica czy nauczą się tej czy innej sekwencji?
Sms tez wysyłają tak: menu,1,4,6,treśc,zielona,+48numer,zielona
a jednak czasami telefon zmieniają.

Arni

unread,
Jun 15, 2006, 2:34:30 PM6/15/06
to
Użytkownik wer napisał:

>
> Nowy protokol pocztowy musi byc maksymalnie o ile to mozliwe oparty na
> obecnym, z kilku wzgledow:<