linux user group brescia

Il 06 maggio 2010 20.01, Francesco <francesco a gibilogic.com> ha scritto:
> 1. "Immobili", a mio avviso, è una parola grossa. Non sono mai stato a
> osservare la volatilità delle black list, tu dici che a livello di blocchi
> c'è poca redenzione? Ovvero, un blocco segnato come spammers rimarrà
> spammers abbastanza a lungo perchè il nostro lavoro rimanga valido per un
> tempo sensato?

Per quello che riguarda questo sottoinsieme di IP, sì.
Ovviamente abbiamo una marea di IP che sono spammer per un solo giorno
(client/server sfondati, ecc).
Ma quest'ultimi sono appunto esclusi a monte dall'elenco su cui stiamo operando.

> Quindi stiamo solo parlando di creare una "cache" locale delle liste nere,
> con tutto il bene e il male che questo comporta, o il tuo piano è molto più
> complesso di così?

Questo lavoro è solo un piccolo pezzetto di un sistema piu' complesso.
Ti faccio un esempio banale.
Proprio perché *il* problema non è tanto ricevere una mail di spam in
più, ma *perdere* delle email vere, a monte di tutto questo ci sta una
whitelist, con l'elenco di tutti i grossi IP/provider che lecitamente
inviano email.

L'elenco su cui stiamo lavorando è un elenco che raccoglie IP che per
definizione/destinazione non possono/devono inviare email.

Non solo. Poiché ovviamente le classi possono comunque essere
spostate/riviste, il nodo cruciale sara' mantenere vivo il controllo
degli elenchi stessi. Controllo che, però, a quel punto sara'
automatizzabile.

Verissimo il controllo a monte degli MTA, ma su questo vanno fatte un
insieme di valutazioni.
Per esempio, il server del lug ha IP di spammer che colpiscono a
raffica, ovvero, nello stesso momento tentato di aprire un numero a
piacere di connessioni.
Se moltiplichi l'effetto, ottieni un impegno non indifferente da parte
di Postfix, nel nostro caso.
Vero è che Postfix non è scemo, e ci sono tuning che si possono
applicare in tal senso. Tanto per citarne alcuni:

smtpd_soft_error_limit = 1
smtpd_error_sleep_time = 20
smtpd_client_connection_count_limit = 40
smtpd_hard_error_limit = 20

Il punto è: possiamo con ragionevole sicurezza tagliare la testa al
toro operando a livello di connessione TCP? evitando quindi tutto il
carico a seguire (apertura della connessione, richieste DNS, ecc).

La risposta alle giuste perplessita' che tu sollevi è che non esiste
*la* tecnica o *il* software di antispam.
Al piu' possiamo unire in un calderone diverse tecnologie e
informazioni, con l'attenzione di non fare piu' danno delle noie che
gia' abbiamo...
Per esempio, esistono tonnellate di blacklist automatiche (spamikaze,
per esempio).
Funzionano in modo interessante, ma se e solo se unite a delle
whitelist, diversamente basta una mail da un client infetto per
bloccare server leciti.

Cerco di non essere prolisso, ma l'argomento è articolato.
Comunque vedremo il tutto nella serata apposita.


Grazie e a presto,
Gelma