Freesco, NND, CDN, EOS

Po wstępnych testach zdecydowałem się na przygotowanie kolejnej wersji programu.
Całość została podzielona na trzy pakiety: dspam, dspam-panel i dspam-skrypty.
Używanie panelu nie jest konieczne, ale umożliwia zobaczenie statystyk dla poszczególnych użytkowników. W panelu nadal nie działa funkcja "retrain", wynika to z problemów dostępu do exima z poziomu panelu. Obawiam się, że to może być trudny problem do rozwiązania.
Jako pierwszy należy zainstalować dspam i przystosować plik konfiguracyjny exim.conf i dspam.conf - przykładowe pliki są zawarte w pakiecie. Jeśli nie chce ktoś korzystac z mysql, to nie musi, należy wówczas opcje mysql zahaszować w konfiguracji. W przeciwnym razie trzeba założyć bazę dspam (dspam.sql jest w pakiecie dspam-skrypty).
Następnie dspam-panel (w pliku admins wpisać login usera, który będzie nim administrował, i podać swoją domenę w pliku konfiguracyjnym). Panel wymaga modułów perla, bez nich nie będzie działać.
Po instalacji dspam-skrypty przechodzimy do katalogu /tmp/dspamconf i wykonujemy zawarte tam skrypty. Utworzą one część potrzebnych plików w katalogu /var/dspam inne zostaną utworzone, gdy program podejmie działanie. Są też skrypty, które wykonają wstępne uczenie programu. Potem program będzie się już uczył na każdym odebranym mailu.
Po dodaniu nowego użytkownika nie ma potrzeby przeprowadzać uczenia, bowiem program używa ogólnej bazy (+baza użytkownika).
Do tej pory nie mam jednoznacznej koncepcji, co robić ze spamem. Domyślnie skrypty zakładają .procmailrc kierujący spam do skrzynki usera w /var/dspam. Jednak to rozwiązanie ma wadę - brak możliwości dokonywania "retrain" dla omyłkowych decyzji programu. Wydaje mi się, że dobrym rozwiązaniem byłoby utworzenie np. użytkownika spamcheck, zmianę uprawnień jego skrzynki pocztowej (żeby była do zapisu dla grupy users) i kierowanie tam bezpośrednio maili zakwalifikowanych jako spam. Daje to adminowi możliwość odbioru poczty i używania opcji "przeadresuj" jaka jest w operze czy thunderbirdzie. W ten sposób omyłkowe spamy można wysłać na adresat-notspam@domena oraz forwardować do użytkownika. Natomiast sam użytkownik przepuszczone spamy odsyła na adresat-spam@domena. W ten sposób program będzie się douczał podczas codziennej pracy.
Na razie w pakiecie brak skryptu uruchamiącego demona dspam, nie jest niezbędny do pracy, choć by się zapewne przydał. Nie ma też automatycznego czyszczenia logu (należy używać dspam_logrotate).
Dobrze byłoby, aby ktoś tę wersję przetestował.
adres: http://nnd-linux-router.one.pl/pkg/dspam-files/

_________________
Belfer.one.PL
Audio Cafe

A dlaczego tak dziwnie? nie da się uruchomić tych scriptów z post_install()?

_________________
Mis'
___________________________________
"Real Men Use Telnet on port 80" (el bid)

Skrypty podzieliłem na części. W założeniu post_install nie jest interaktywne i to wystarczający argument.
Ponadto np. skrypt, który zapisuje .procmailrc każdemu użytkownikiowi, trzeba najpierw sobie wyedytować, bo to jest kwestia decyzji, co robić ze spamem. Nie ma jedynego dobrego sposóbu, wolę, żeby użytkownik sam zadecydował.

_________________
Belfer.one.PL
Audio Cafe

ok, rozumiem.



to znaczy, że te scripty z /tmp każdy użytkownik wykonuje ze swojego konta, tak? Jesli tak jest to co z użytkownikami nie mającymi dostępu do shella?
Największe moje zdziwienie budzi umieszczenie tego w /tmp... to nie jest dobre miejsce, ja np. dośc regularnie czyszczę ten katalog.
Kolejne wątpliwosci - co się stanie w przypadku gdy te scripty zostaną, jak napisałeś wyedytowane, i wypuścisz nową wersję pakietu? Pacman będzie miał pliki, których sumy kontrolne sa różne od zapisanych w bazie więc ich nie zupgraduje... Może lepszym rozwiazaniem byłoby takie przygotowanie scriptów, aby akceptowały parametry wywołania i umieszczenie ich w /usr/bin? Nadal nie rozwiaże to jednak problemu z userami nie mającymi dostępu do shella... lub zbyt przestraszonymi aby skorzystać z konsolowego edytora.

_________________
Mis'
___________________________________
"Real Men Use Telnet on port 80" (el bid)

Cały proces instalacji i konfiguracji jest wykonywany przez admina. Użytkownicy nie muszą w skrajnej sytuacji nic robić, mogą korzystać z panelu www, ale czy to będą robić...
Na dobrą sprawę jedyny skrypt, który może się przydać wielokrotnie to skrypt zapisujący .procmailrc, bo admin może po jakimś czasie zechcieć zmienić sposób zarządzania spamem, no i ewentualnie skrypty do treningu... z tego powodu umiściłem to w /tmp, bo w zasadzie można i należy to po skonfigurowaniu skasować.
Właśnie rozważam jak to dalej zmienić, bo paczki na razie są tylko w moim repzoytorium i zanim nie będę miał jakiejś koncepcji nie chcę umieszczać ich nawet w testing.
Generalnie sądzę, że warto się programem zainteresować, bo przy stosunkowo małym nakładzie pracy daje wspaniałe efekty.

_________________
Belfer.one.PL
Audio Cafe

jeszcze gorzej... przeciez pacman zgłupieje jak mu usuniesz pliki, które on ma zapisane w bazie pakieów...

_________________
Mis'
___________________________________
"Real Men Use Telnet on port 80" (el bid)

Na dzień dzisiejszy to akurat jest najmniejszy problem (można użyć pacman -R).
Większym problemem jest ostateczna decyzja co do wstępnie zaproponowanego użytkownikom sposobu zarządzania spamem.

_________________
Belfer.one.PL
Audio Cafe

pacman -R usunie cały pakiet, a i tak w przypadku braku plików będzie krzyczał. Nie do końca rozumiem jakie zastosowanie miałoby w tym miejscu to polecenie.



zaraz, to ten panel nie śłuży do tego? Rozumiem, że nie koniecznie trzeba go instalowac, ale jak jest to chyba własnie po to (wiem o statystykach, ale uważam je za dodatek i wodotrysk).
a co z forwardem? dodatkowe konto na które forwardujemy każdy przepuszczony spam i drugie na które idą zaznaczone jako spam maile, które spamem nie są...

_________________
Mis'
___________________________________
"Real Men Use Telnet on port 80" (el bid)

Panel ma funkcjonalność niestety ograniczoną bezpieczeństwem. Wczoraj odkryłem, jak można wykonywać jednak "retrain" za pomoca panelu. Ale i tak decyzja o sposobie postępowania ze spamem nie należy do panelu i użytkownika, a do admina i to na etapie konfiguracji programu.
Można przekazywać spam na osobne konto (na dwa sposoby) i to admin będzie dokonywał zmian (forward dobrej poczty na konto usera), a użytkownik ewentualnie będzie wykonywał redirect dla przepuszczonych spamów.
Można zrobić tak, aby spam trafiał do specjalnej skrzynki widocznej w panelu (dostęp do tego ma użytkownik i admin), ale jest to wersja bardziej kłopotliwa dla admina, jeśli użytkownicy sami nie będą chcieli się o to troszczyć...
Dodatkowe konta - takich nie ma. Każdy spam można odesłać na konto user-spam@domena (nie ma takiego konta, to tylko informacja dla dspam, który przekwalifikuje dany mail). Niewinny mail można odesłać na use-notspam@domena (również funkcja dspam). Jedyne dodatkowe konto, o którym mówiłem, to np. konto spamcheck, które zakładamy sobie do kontrolowania tego co znajdzie się w skrzynce z dspam.

_________________
Belfer.one.PL
Audio Cafe