On Wed, 2007-07-04 at 08:01 +0200, wer wrote:
> Spam składający się ze słów kup viagrę - www.mojaviagra.com też w takim
> razie jest nieszkodliwy. Bo przecież prawie nie obciąża serwera. Liczy
> się sam fakt, że ktoś narzuca mi większe obciążenie serwera. Przy jednym
> mailu to jest pomijalne. Jeśli wszyscy by stosowali greylisting, to z
> 200 tyś. maili dziennie robi się 400 tyś.

Gdybyś dzisiaj włączył ten serwer ( u nikogo nie jest on jeszcze
zwhitelistowany na skutek udanych transmisji w przeszłości ) i każdy
z tych maili miał trafić do innego spośród 200 tysięcy serwerów -
tylko wtedy musiałbyś zrobić 200 tysięcy transmisji więcej tego dnia.

Byłyby to jednak krótkie transmisje - kończyłyby się na wczesnym
etapie konwersacji smtp ( żadnej mowy o przesyłaniu maili dodatkowe
200 tysięcy razy być więc nie może ). Każdy z maili miałby maks. 15-30
minut opóźnienia ( Twój czas odstępu między przeglądaniem kolejki ),
przeciętne statystyczne opóźnienie przesyłki byłoby równe czas odstępu
między przeglądaniem kolejki/2 ( 7.5min jeśli 15, 15 min jeśli 30 ).

> To daje 200 tyś dodatkowych
> prób przesyłki. Greylisting był, jest i będzie systemem, który obciąża
> nadawcę. Na zasadzie, żeby mnie nie okradli, każdemu kto się do mnie
> zbliży zabiorę 1 grosz.

Te 200 tysięcy transmisji _tego_dnia_, przy najczarniejszym możliwym do
wyobrażenia scenariuszu, to _tego_dnia_ mniej niż paręset megabajtów
ruchu ( byłem hojny - dałem 1 KB na transmisję ). Odpowiedz sobie
jaka to różnica na rurze do węzła pocztowego, który ma ją wyskalowaną
do wysyłania 200 tysięcy maili od siebie, a ponadto przyjmuje ileś
i obsługuje ruch userów dobijających się do skrzynek.

W życiu codziennym większość ruchu Twoich userów leci do
kilkudziesięciu-kilkuset dużych węzłów pocztowych, do których wznowić
i zwhitelistować się w greylistingu musisz raz na parę dni ( jedno
wznowienie dla jednej przesyłki na kilka(dziesiąt) tysięcy przesyłek
do danego węzła ). Narzut jest pomijalny. Jest pomijalny również
w kolejkach - pewnie ze sto razy więcej maili masz w kolejkach, bo
docelowy józio17 w danym portalu ma przekroczoną quotę.

--
Mirosław "Psyborg" Jaworski
GCS/IT d- s+:+ a C++$ UBI++++$ P+++$ L- E--- W++(+++)$ N++ o+ K- w-- O-
M- V- PS+ PE++ Y+ PGP t 5? X+ R++ !tv b++(+++) DI++ D+ G e* h++ r+++ y?
"I never forget a face, but in your case I'll be glad to make an exception."

do góry

Dnia Thu, 05 Jul 2007 15:19:29 +0200, Mirosław Jaworski napisał(a):

> On Tue, 2007-07-03 at 21:36 +0200, wer wrote:
>> Poza tym spamerzy coraz częściej stosują ponowną wysyłkę. Już zetknąłem
>> się z czymś takim jak najpierw pusty mail, za 10 minut następny już z
>> treścią.
>
> Jeśli greylisting wpuszcza takiego maila, to jest źle zaimplementowany.
> Greylisting musi umieć rozpoznawać prawdziwe wznawianie od udawanego,
> którego niektórzy spamerzy się nauczyli.

Ooo, a jak się implementuje takie rozpoznawanie?

--
Piotr Gackiewicz
Intertele S.A. - operator systemów ITL.PL i DOMENY.ITL.PL
al. T. Rejtana 1, 35-326 Rzeszów
TEL: +48 17 8507580, FAX: +48 17 8520275, INFOLINIA: 0 801 335523

do góry

Mirosław Jaworski wrote:
>
> Gdybyś dzisiaj włączył ten serwer ( u nikogo nie jest on jeszcze
> zwhitelistowany na skutek udanych transmisji w przeszłości ) i każdy
> z tych maili miał trafić do innego spośród 200 tysięcy serwerów -
> tylko wtedy musiałbyś zrobić 200 tysięcy transmisji więcej tego dnia.

Fajnie jest jak masz jedną domenę na serwerze. Przy ponad 10 tyś. domen
wygląda to jednak inaczej. Whitelisting jest robiony zwykle nie na IP
serwera, a na triplet ip serwera, adres nadawcy, adres odbiorcy.

>>To daje 200 tyś dodatkowych
>>prób przesyłki. Greylisting był, jest i będzie systemem, który obciąża
>>nadawcę. Na zasadzie, żeby mnie nie okradli, każdemu kto się do mnie
>>zbliży zabiorę 1 grosz.
>
>
> Te 200 tysięcy transmisji _tego_dnia_, przy najczarniejszym możliwym do
> wyobrażenia scenariuszu, to _tego_dnia_ mniej niż paręset megabajtów
> ruchu ( byłem hojny - dałem 1 KB na transmisję ). Odpowiedz sobie
> jaka to różnica na rurze do węzła pocztowego, który ma ją wyskalowaną
> do wysyłania 200 tysięcy maili od siebie, a ponadto przyjmuje ileś
> i obsługuje ruch userów dobijających się do skrzynek.

A ile dodatkowych operacji? Każda próba wysyłki to nie tylko połączenie
z serwerem docelowym. Przeczytanie kolejki, im większa kolejka tym
dłużej to trwa. Potem resolving nazwy, w najlepszym przypadku sięgnięcie
do cache resolvera, w gorszym odpytanie lokalnego serwera DNS i ma on
rekord w cache, w najgorszym przypadku lokalny DNS musi się odpytywać
rootDNS o adres serwera obsługującego tę domenę, potem znów odpytać sie.

Czyli sporo tego leci, oczywiście wzrasta też wielkość pamięci
wykorzystywanej na cache.

Ponowne wysłanie maila to sporo operacji, dyskowych, sieciowych,
systemowych.

>
> W życiu codziennym większość ruchu Twoich userów leci do
> kilkudziesięciu-kilkuset dużych węzłów pocztowych, do których wznowić
> i zwhitelistować się w greylistingu musisz raz na parę dni ( jedno
> wznowienie dla jednej przesyłki na kilka(dziesiąt) tysięcy przesyłek
> do danego węzła ). Narzut jest pomijalny. Jest pomijalny również
> w kolejkach - pewnie ze sto razy więcej maili masz w kolejkach, bo
> docelowy józio17 w danym portalu ma przekroczoną quotę.

Ciekawe, że ciągle mam w kolejce maile na onet, gmail. Przecież
codziennie tam lecą przesyłki. W tej chwili ok. 10 - 15% maili w kolejce
to greylisting.

--
wer

nie odpisuj na adres b...@n...pl
wlasciwy adres a...@o...pl

Jestem przeciwnikiem kary smierci, ale dla przykladu powinno sie
powiesic 100 spamerow w miejscach publicznych.

do góry

Piotr Gackiewicz wrote:
> Dnia Thu, 05 Jul 2007 15:19:29 +0200, Mirosław Jaworski napisał(a):
>
>> On Tue, 2007-07-03 at 21:36 +0200, wer wrote:
>>> Poza tym spamerzy coraz częściej stosują ponowną wysyłkę. Już zetknąłem
>>> się z czymś takim jak najpierw pusty mail, za 10 minut następny już z
>>> treścią.
>> Jeśli greylisting wpuszcza takiego maila, to jest źle zaimplementowany.
>> Greylisting musi umieć rozpoznawać prawdziwe wznawianie od udawanego,
>> którego niektórzy spamerzy się nauczyli.
>
> Ooo, a jak się implementuje takie rozpoznawanie?
>

ifconfig nfe0 down

--
tkniaz

do góry

On Fri, 2007-07-06 at 11:10 +0200, wer wrote:
> Mirosław Jaworski wrote:
> >
> > Gdybyś dzisiaj włączył ten serwer ( u nikogo nie jest on jeszcze
> > zwhitelistowany na skutek udanych transmisji w przeszłości ) i każdy
> > z tych maili miał trafić do innego spośród 200 tysięcy serwerów -
> > tylko wtedy musiałbyś zrobić 200 tysięcy transmisji więcej tego dnia.
>
> Fajnie jest jak masz jedną domenę na serwerze. Przy ponad 10 tyś. domen
> wygląda to jednak inaczej. Whitelisting jest robiony zwykle nie na IP
> serwera, a na triplet ip serwera, adres nadawcy, adres odbiorcy.

Zbyt agresywnie imho. Oczywiście wolna wola twórcy. Istotnie,
w przypadku takiej implementacji narzut będzie większy niż
w implementacji o której myślę.

W systemie, który jest pod moją opieką ( żeby nie było, że się
przechwalam swoim rozwiązaniem - głównym, prawie wyłącznym autorem
rozwiązania, jest mój koadmin, który jest bardziej zorientowany
na usługi mailowe niż ja ) do niedawna triplet ( a od niedawna kwartet
- sygnalizowana przeze mnie wcześniej weryfikacja czy wznowienie
jest prawdziwe czy to tylko fake ) jest używany tylko do weryfikowania
czy wznowienie jest ok, whitelistujemy adres ip jako poprawne źródło
ruchu pocztowego.

Żeby dać wyobrażenie, że nie mam na myśli rozwiązania trzepakowego -
w dniu wczorajszych w logach mam prawie 700 000 unikalnych qid,
zwhitelistowanych jest w chwili obecnej 60000+ węzłów pocztowych,
rozwiązanie jest oczywiście w pełni skalowalne liniowo.

> > Te 200 tysięcy transmisji _tego_dnia_, przy najczarniejszym możliwym do
> > wyobrażenia scenariuszu, to _tego_dnia_ mniej niż paręset megabajtów
> > ruchu ( byłem hojny - dałem 1 KB na transmisję ). Odpowiedz sobie
> > jaka to różnica na rurze do węzła pocztowego, który ma ją wyskalowaną
> > do wysyłania 200 tysięcy maili od siebie, a ponadto przyjmuje ileś
> > i obsługuje ruch userów dobijających się do skrzynek.
>
> A ile dodatkowych operacji? Każda próba wysyłki to nie tylko połączenie
> z serwerem docelowym. Przeczytanie kolejki, im większa kolejka tym
> dłużej to trwa. Potem resolving nazwy, w najlepszym przypadku sięgnięcie
> do cache resolvera, w gorszym odpytanie lokalnego serwera DNS i ma on
> rekord w cache, w najgorszym przypadku lokalny DNS musi się odpytywać
> rootDNS o adres serwera obsługującego tę domenę, potem znów odpytać sie.

Wznawiasz wysyłkę po parunastu minutach, więc odpowiedź masz w cache'u
swojego resolvera. ttl mniejszy niż czas obrotu kolejki zdarza się
rzadko, niemniej ilość takich rekordów nie jest zerowa, żeby więc
być w porządku prowadząc taką dyskusję, należy przyznać, że takowe są;
tylko w ich przypadku będziesz musiał wygenerować zapytanie, na które
nie będziesz miał odpowiedzi w cache'u i będzie ono musiało opuścić Twój
węzeł wychodząc przez rurę na zewnątrz ). Jest to jednak sytuacja rzadka
( wstępnie zgrubnie szacuję, że rekordów dla których ttl jest krótszy
niż czas po którym wypadałoby wznowić jest 2% ). Tak czy inaczej -
udział ruchu dot. dns w całości ruchu na rurze jest niewielka, ilość
ruchu będącego efektem greylistingu, która jest jego niewielkim
podzbiorem - procentowo w całości ruchu znikoma.

> Czyli sporo tego leci, oczywiście wzrasta też wielkość pamięci
> wykorzystywanej na cache.

Nie podnosisz chyba limitu? Spaść może Ci co najwyżej efektywność
cache'a ( postrzegana jako hit ratio - odpowiedziane z cache'a
vs wszystkie obsłużone zapytania, w tym te po które musiałeś
sięgnąć na zewnątrz ). Jeśli skarżysz się na spowodowane greylistingiem
wcześniejsze "wymywanie danych" to znaczy, że Twój cache już przed
jego włączeniem był za mały. Nie jest to jednak problem greylistingu
a efekt już wcześniejszego nieodpowiedniego wyskalowania cache'a
resolwera w porównaniu do ruchu który otrzymuje i mógłby cache'ować.

Ciekawe jest dla mnie, że ze spokojnym sumieniem winisz greylisting
jako sprawcę spadku skuteczności resolwera, a dzikich zapytań
pochodzących od zarażonych desktopów nie :) Ilość zapytań będących
efektem greylistingu w porównaniu do tych drugich - zgadłeś - znikoma :)

> > W życiu codziennym większość ruchu Twoich userów leci do
> > kilkudziesięciu-kilkuset dużych węzłów pocztowych, do których wznowić
> > i zwhitelistować się w greylistingu musisz raz na parę dni ( jedno
> > wznowienie dla jednej przesyłki na kilka(dziesiąt) tysięcy przesyłek
> > do danego węzła ). Narzut jest pomijalny. Jest pomijalny również
> > w kolejkach - pewnie ze sto razy więcej maili masz w kolejkach, bo
> > docelowy józio17 w danym portalu ma przekroczoną quotę.
>
> Ciekawe, że ciągle mam w kolejce maile na onet, gmail. Przecież
> codziennie tam lecą przesyłki. W tej chwili ok. 10 - 15% maili w kolejce
> to greylisting.

W chwili obecnej we wszystkich kolejkach do wypchnięcia mam 16000 maili,
łącznie zajmujących niecałe 1.2 GB. Personalnie uważam to za
_bardzo_małą_ ilość. Nawet jeśli 20% to efekt greylistingu, to te
~3000 maili i 250MB danych więcej to przy całej skali operacji żaden
problem.

--
Mirosław "Psyborg" Jaworski
GCS/IT d- s+:+ a C++$ UBI++++$ P+++$ L- E--- W++(+++)$ N++ o+ K- w-- O-
M- V- PS+ PE++ Y+ PGP t 5? X+ R++ !tv b++(+++) DI++ D+ G e* h++ r+++ y?
"Those are my principles. If you don't like them I have others."

do góry

Krzysztof Halasa wrote:

> RoMan Mandziejewicz <r...@p...pl> writes:
>
>> [... 7 kawałków ...]
>>
>> Co ten Twój czytnik wyrabia?
>
> Tak przekodowuje z UTF-8... Ale nie powinienes tego widziec, chyba
> ze Twoj tez wyrabia dziwne rzeczy (i dodatkowo niezgodne z RFC) :-)

knode wyświetla nieciekawie. Zdaje się gdyby było w nagłówkach
content-disposition: inline to by wyświetlał po ludzku.

--
Arek, arekmx|gazeta.pl

do góry

arekmx <a...@g...pl> writes:

> knode wyświetla nieciekawie. Zdaje się gdyby było w nagłówkach
> content-disposition: inline to by wyświetlał po ludzku.

Przy text/plain widzi mu sie cos innego domyslnie? :-)
--
Krzysztof Halasa

do góry

Krzysztof Halasa <k...@p...waw.pl> writes:

> Obawiam sie ze wczesniej doczekam sie zatwierdzenia UTF-8 w pl.*
> (i problem zginie) niz tego, ze ktos (lub ja) zrobi optymalne
> przekodowania do ISO 8859 / ASCII w Gnus/Xemacs.

Ale o co chodzi? Mój gnus nie dzieli polskiego tekstu na ó w 8859-1 i
resztę w 8859-2.

MJ

do góry

Michal Jankowski <m...@f...edu.pl> writes:

>> Obawiam sie ze wczesniej doczekam sie zatwierdzenia UTF-8 w pl.*
>> (i problem zginie) niz tego, ze ktos (lub ja) zrobi optymalne
>> przekodowania do ISO 8859 / ASCII w Gnus/Xemacs.
>
> Ale o co chodzi? Mój gnus nie dzieli polskiego tekstu na ó w 8859-1 i
> resztę w 8859-2.

Moj tez nie, jesli nie cytuje nic w UTF-8 i nastepnie nie wysylam
w 8859. Z tym, ze nie wiem czy to wina samego Gnusa, czy XEmacsa.
Uzywasz XEmacsa? Ktorych wersji jednego i drugiego?
--
Krzysztof Halasa

do góry

Krzysztof Halasa <k...@p...waw.pl> writes:

> Moj tez nie, jesli nie cytuje nic w UTF-8 i nastepnie nie wysylam
> w 8859.

Zainteresuj się pakietem Mule-UCS (ja używam Emacsa bez 'x' ale z
opisu wynika, że pod XEmacsem też działa).

MJ

do góry