[PLUTO-help] spam philosophy - era: e-mail & cose strane

[Beppe]

Parlando di "Re: [PLUTO-help] spam philosophy - era: e-mail & cose strane" 
Stefano Callegari ha scritto:

<cut>

> Se chi amministri è contento delle tue politiche, allora non posso che
> complimentarmi.

Piu' che contento è informato: prima dell'attivazione di qualsiasi account 
avverto sempre della cosa.
Se un utente non intende che la posta a lui diretta venga rigettata
senza il suo consenso (il che non mi è mai capitato), per me problemi non c'è 
ne. 
Le whitelist x `user` è cmq. una via possibile :o)

<cut>

> Sono rimasto in lista per questo passaggio.
>
> A parte chiederti come e con cosa lo fai, in generale la doc anti spam
> dice di ignorare il messaggio in quanto altrimenti segnaleresti
> l'account come attivo e quindi ti apriresti a chi sa quanti spammer.
>
> Immagino che la cosa ti sia obbligatoria in quanto avrai IP statici e
> quindi facilmente si possa pensare che dietro esiste un account.

Vero e falso...

Considera che moltissimi messaggi vengono rispediti al mittente con messaggio:
"unknow user" o Domain Not Found", il che non fa assolutamente presagire che 
l'account esista... anzi !

Ma considera anche che:

non poi sapere a priori che si tratti di SPAM o di posta lecita e in questi 
casi il messaggio amministrativo, è direi neccessario

Prendi gli errori di battitura, piuttosto frequenti; un conoscente vuole 
inviarmi una mail, ma per errore anzichè a beppe a ... la manda a bepe a ...

Come sarebbe possibile informarlo di quanto accaduto ? Ecco che il messaggio 
di ritorno è necessario.

Per quanto riguarda lo SPAM vero' è proprio, direi che molto è applicabile 
anche dalle possibilità offerte dall'SMTP.

Nel caso di postfix apprezzo la sua flessibilità soprattutto nella 
ridefinizione di classi strettamente personali ma vediamo un po...

Se si tratta di liste pubbliche... il messaggio di ritorno è in realtà
il messaggio ottenuto dalla lista stessa ma è cmq. mooolto vago:

// Fresco, appena arrivato :o)

In:  MAIL FROM:<pscgbydr a derechoshumanos.com>
 Out: 250 Ok
 In:  RCPT TO:<sales a dominio.tdl>
 Out: 554 Service unavailable; [213.23.12.250] blocked using list.dsbl.org,
     reason: http://dsbl.org/listing?ip=213.23.12.250

Da notare, che RCPT TO:<sales a dominio.tdl>, non esiste, ma il messaggio di 
ritorno non è "unknow user"; questo perchè il controllo sulla casella il 
cosidetto "recipient", è successivo infatti:

prima le restriction sui client:

smtpd_client_restriction = permit_mynetworks, hash: /etc/postfix/client, 
reject_maps_rbl...

Dove client[.db] contiene ad esempio:

eng.be3a.com   WHITELIST <----- da notare blacklistato ovunque :o)

Questa WHITLIST, di cui parlavo inizialmente è definita alla stessa maniera 
con cui sono definite le altre, ma fa qualcosa di diverso... la flessibilità 
in questo cosa non è da poco IMHO.

Passa succcessivamente alle restriction sui sender... qui oltre a rispedire 
indietro tutti coloro che si presentano con fake domain, si passa il 
controllo pure al sender.db...

TOP--SITES.COM   550  Your domain send much SPAM

oppure 

1.2.3.4	550 No monezza please :o)

....

Anche qui posso definire un messaggio a mio piacimento, oppure usare
il semplice REJECT, se non intendo dire altro.

In ogni caso potrei anche solo generare un Warning e lasciar passare il tutto 
se volessi fare solamente una statisticha sul dominio da controllare.
Lo stesso comportamento puo' essere applicato ed esteso anche nel caso 
utilizzi header_check o body. Quindi non aggiungerei altro.

Rimangono le restriction sui "recipient" (le caselle); questa sarebbereo state 
le restrizioni tali da generare il messaggio "unknow users" di cui parlavamo 
sopra, ma avendo trovato un motivo per bloccare il messaggio prima, tutta la 
parte in eccedenza è stata tralasciata.

Tuttavia nel file di configurazione è tua facolta poter gestire il tipo di 
messaggio da rispedire in tutti gli altri casi esempio lampante:

invalid_hostname_reject_code (default:501)

Quindi in conclusione e per tornare alla tua domanda, sarebbe meglio non dare 
ulteriori indicazioni sull'esistenza o meno di un account, per i motivi da te 
citati, ma nella maggior parte preferisco notificare il motivo del rigetto al 
mittente, in quanto crdeo di aver riscontrato che spesso e volentieri la cosa 
non mi cagiona ulteriori problemi.

Detta fra me e te... ho pochissimi utenti con account info a ... che fortuna la 
mia  :o)  

Sperando che la spiegazione si stata sufficentemente eloquente :o) ti saluto. 
Beppe
-- 
GnuPG Public KEY: 
--->[http://www.bpnets.org/beppe.asc]