Własny czytniku już mam, ale pytam jak zrobić i czy w ogóle da się w gotowych, których nie będziemy studiować. Retorycznie pytam, bo było, że nie ma problemu. Ja myślę, że jest, że w zasadzie tylko po Path można prosto filtry ustawiać a i one zdaje się będą działały po pobraniu dopiero.
Nie wiem. Ja filtruję na serwerze. Jedyny czytnik, który znam na tyle, żeby móc odpowiedzieć, to ten, którego ja używam -- i wydaje się, że nie ma tam aż takich możliwości (bez edycji źródeł).
Jeśli ma działać bez pobrania, to musi ciąć po tym, co jest w overview. Na chmurce są to domyślne nagłówki, ale wśród nich jest też Subject.
$ echo list overview.fmt | nc news.chmurka.net nntp | grep : Subject: From: Date: Message-ID: References: Bytes: Lines: Xref:full
Adam Górski w news:uk7ds6$eol$1$ snipped-for-privacy@news.chmurka.net
nie sprawdzalem, ciekawym, czy to cudo moze byc skuteczne w lapaniu spamu usenetowego...:
No tak, trochę mi się dwa podejścia skleiły, że po Subject jest w overview ale zakresu liter tak łatwo nie da się wybrać i pozostaje np filtrowanie googlegroups w Path a wtedy już tego nie ma w overview.
Tak generalnie na tych kilka serwerów, które są w Polsce to dałoby się je jednak obsłużyć gdyby administratorzy mieli na to czas. Bo wracając, do artykułu sprzed wielu miesięcy, jednak trzeba trochę czasu poświęcić na to administrowanie a nie, że "każdy sobie może postawić i nic to nie kosztuje".
Są różne narzędzia, ale w przypadku takich bayesowskich zawsze jest ryzyko fałszywek. Eternal September filtruje spamassassinem (też bayesowski) i są fałszywki, szczególnie w lokalnych hierarchiach (kogutki, "a a" i inne takie już się na te filtry połapały, a choć wartość merytoryczna ich postów jest czasem jaka jest, to nie są to masowe spamy, więc nie powinny być wycinane automatycznie).
Sam wychodzę z założenia, że lepiej przepuścić 10 spamów, niż jeden nie-spam przez pomyłkę wyciąć (bo spam w razie czego można sobie oczami przelecieć i zignorować, a jak normalny post na grupę nie dojdzie, to nie wyczaruje się go z powrotem), więc pisząc filtry traktuję to jako priorytet (m.in. stąd grupy chmurka.spam.* jako taka siatka bezpieczeństwa, w razie gdyby było cięte coś, co nie powinno).
Można po Message-ID, jeśli nie boisz się wyciąć kogoś, kto sobie wpisał google'a w Message-ID, choć nie nadaje z niego.
Zakres liter łatwo jest sprawdzić programowo, ale jeśli poruszasz się tylko w zakresie sposobów filtrowania, które przewidział twórca czytnika, i akurat tego nie przewidział, to faktycznie może być problem.
Tak, to jest właśnie kwestia czasu, a on z kolei idzie w parze z tym, czy dany admin korzysta z Usenetu. Jak korzysta, to sam widzi, co się dzieje. Jak nie korzysta, to po prostu serwer sobie stoi i dopóki nikt mu nic nie zgłosi, to nawet może nie wiedzieć, że coś się dzieje, bo z logów, które przychodzą codziennie na maila, nie zawsze to wynika (już pomijając, czy ktoś te logi czyta, czy po jakimś czasie już kasuje bez czytania).
W dniu 8.12.2023 o 20:45, Arnold Ziffel pisze:
Na grupę przychodzi około 9000 artykułów. 3 artykuły na sekundę to 3000 sekund czyli 50 minut dziennie jedna grupa. Dobrze że Usenet nie jest już tak popularny.
Myślę, że dobry pomysł. Aczkolwiek tego spamu już nie widzę.
O to pytałem, jak zwykły ludzik ma sobie to odfiltrować.
Ale jak korzysta to czasu ma mniej. :-)
To jest inna sprawa, że można nie wiedzieć, że jest jakiś problem. Podstawowy jak dla mnie to posiadanie czasu właśnie na to, by rozwiązać kolejny problem jaki pojawił się zamiast sobie pobiegać, pooglądać tv lub cokolwiek innego życiowego. Administrator zawodowy właśnie tym administrowaniem zajmuje się a hobbysta może mieć tysiąc ciekawszych i krótkich tematów niż pilnowanie serwera.
Pan Arnold Ziffel napisał:
W ogólności można po "Content-Transfer-Encoding: base64", przynajmniej w grupach pl.*, w których pisze się po polsku. Teksty w europejskich językach będą przez większość czytników zakodowane jako "8bit" (a Google Groups używają "quoted-printable"). Dla tekstów w całości w językach azjatyckich nie jest to optymalne podejście -- Google Groups używa wtedy base64. W slrn dałem dodatnią punktację dla "base64" -- nic "normalnego" się na to nie załapało w ostatnich kilku tysiącach wiadomości na grupie.
W dniu 10.12.2023 o 16:57, Jarosław Sokołowski pisze:
A nie można po dwu literkach "o" w Path?
io pisze:
Lepiej, ale nie o taki filtr chodziło. Jak ktoś chce wyciąć *wszystko* z Google Groups, to zamiast kombinować z nazwami serwerów w Patch, łatwiej i pewniej filtrować po "User-Agent: G2/1.0" -- tu żadnych pomyłek filtra nie należy się spodziewać. Sam tak zresztą od lat robię -- tnę googla dużym ujemnym scorem, ale kilku nieidiotów piszących stamtąd odplonkowuję taką samą dodatnią punktacją. To rozwiązanie niemal idealne, żaden spam czy inne śmieci nigdy mi się nie wciskają.
Wyżej pokazałem jak odcedzić niełacińskie wiadomości. To powinno być skuteczne niezależnie od źródła (chociaż poza Google Groups takich źródeł nie ma).
W dniu 11.12.2023 o 14:35, Jarosław Sokołowski pisze:
No ale właśnie nie bardzo chcemy filtrować wszystko. To jest tylko jakaś konieczność z braku lepszych kryteriów.
No i widzisz, znowu nie da się zastosować do przeciętnego czytnika.
No nie, to jest filtrowanie po kodowaniu, zupełnie absurdalne choć oczywiście może jest tak, jak piszesz, że działa ok.
io pisze:
Po co w takim razie było wyskakiwać z pomysłami filtrowania podwójnego o? Dla mnie to jest najlepsze kryterium. Ja tak *chcę* a nie *muszę*.
No właśnie tego nie widzę. Widzę, że da się i że działa.
W polskim tłumaczeniu "kodowaniem" nazywa się to, co jest w nagłówku "Content-Type", czyli np. "charset=iso-8859-2" lub "charset=utf-8". Tu chodzi o nagłówek "Content-Transfer-Encoding", z naciskiem na "Transfer". To zupełnie co innego niż charset.
W dniu 11.12.2023 o 16:40, Jarosław Sokołowski pisze:
Kasowanie podwójnych literek "o" jest zdecydowanie poprawniejsze niż filtrowanie po kodowaniu.
Ale ja się na tym znam, po ci mi to tłumaczysz.
io pisze:
Taka jest naga bab^H^H^Hprawda.
Jarek
W dniu 11.12.2023 o 17:47, Jarosław Sokołowski pisze:
Człowieku, wielokrotnie wypowiadałem się na temat base64 w kontekście łamania więc co Ty mi tu. Między innymi z tego wynika, że takie kodowanie zawartości mogłoby zostać zastosowane celowo dla zupełnie dowolnego języka, kodowania znaków itp itd. A Ty sugerujesz by po tym filtrować.
a a snipped-for-privacy@gmail.com napisał(a):
Bo nadal do Ciebie nie dociera.
No popatrz, a Ty zajmujesz się rozsyłaniem spamu z Google Groups i jakoś kapcza Ci nie przeszkadza. Poza tym ciekawe ile na tym zarabiasz. Np. dzisiaj wysłałeś na tę grupę trzy spamy. Ile za to dostałeś?
io w news:ul2up3$ddln$ snipped-for-privacy@news.icm.edu.pl [.................]
w zasadzie tak to wyglada: " to faktycznie może być problem" (np. o ile tajski spam dal (mi) sie "jakos" opanowac, o tyle z pozostalym jest kiepsko; w dodatku jest to zapewne kwestia czytnika, prosty czytnik na tzw. 99% nie daje nawet srednich mozliwosci dla regul blokowania tego, co teraz szaleje i cala nadzieja w adminach serwerow usenetowych, ale z drugiej strony... dlaczego im ma sie az tak chciec bawic w "straz nocna"?
W dniu 11.12.2023 o 23:10, 1634Racine pisze:
No bo to albo chce się świadczyć usługę więc o nią dba albo nie chce i nie dba :-) Brak tu zapewne pieniędzy by komuś się chciało. Usenet musi upaść :-)
Żeby tak prosty czytnik umożliwiał podpięcie skryptu filtrującego, to można byłoby filtrować w zasadzie wszystko w dowolny sposób. Serwer umożliwia. Wchodzi artykuł, odpalana jest funkcja w skrypcie, która dostaje ten artykuł, i to skrypt decyduje, czy artykuł przepuścić, czy zablokować.
Nie ma w skrypcie możliwości łatwego repostowania artykułu na inną grupę (lub ogólnie edycji artykułu), ale to skrypt, więc można sobie to dowolnie oprogramować, zapisywać sobie te artykuły, przetwarzać w dowolny sposób zanim zostaną przepuszczone lub odrzucone.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.