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