Newsgroup: it.news.net-abuse
Titolo: Il  record  SPF  piu' semplice

Mi sto studiando la questione per limitare lo spam che forgi email con 
mio dominio.
La mia situazione è molto semplice:
- Il server smtp all'ip 1.2.3.4 è l'unico autorizzato a spedire posta 
per il dominio 
pippoplutopaperino.it
 .
- Il dominio 
pippoplutopaperino.it
 punta all'ip 1.2.3.4 .
- Il record MX di 
pippoplutopaperino.it
 punta all'ip 1.2.3.4 .
- Le email vengono spedite dal server stesso oppure da connessioni smtp 
ssl (ma credo che questa informazione non sia necessaria)
Mi date una dritta?

 Mi date una dritta?
http://www.openspf.org/
Fatto apposta.
-- 
Flavio Visentin
2006: l'onestà  2007: la storia  2008: la leggenda  2009: il mito epico
2010: l'apoteosi!! 3 TITULI!!! Scudetto, Coppa Italia, Champions League
 
http://www.zipman.it/ot/Gufi_Rosicate.jpg

 Mi date una dritta?
v=spf1 a mx -all


E non aspettarti che ti serva a qualcosa...
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 E non aspettarti che ti serva a qualcosa...
Perché?



Probabilmente perche' va configurato anche il server mail
adeguatamente.
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 v=spf1 a mx -all
Grazie mille, direi che va bene.
Ho solo una curiosità. Ammettiamo che io usi solo "mx", senza "a". 
Quindi solo il server indicato dal record mx viene considerato valido.
Se il record mx non contiene un ip (1.2.3.4) ma un dominio 
(
mx.pippoplutopaperino.it
), cosa succede?
Il server che controlla il record spf segue la catena di risoluzione dei 
domini, oppure pretende un ip?
Perché appunto nel mio caso al record a è indicato l'ip mentre al record 
mx è indicato un dominio di terzo livello.

 adeguatamente.
Cosa intendi? Quale configurazione?

 mx è indicato un dominio di terzo livello.
A differenza di quello che avevo scritto nel primo messaggio, ahi ahi 
ahi a me.



E' sempre cosi'. Comuque se hai paura di non risalire al server
specificato nel record MX puoi usare un redirect.
Nella zona per il tuo dominio (eg. 
ciccio.it
):
v=spf1 redirect=
pippoplutopaperino.it
Nella zona di 
pippoplutopaperino.it
v=spf1 mx -all
Il server fara' una query al DNS per ricavare il record SPF di
ciccio.it
 e verra dirottato su 
pippoplutopaperino.it
 dove trovera'
tutto quello che gli serve.
Il redirect non e' necessario ma puo' avere i suoi vantaggi se devi ad
esempio aggiungere/togliere server autorizzati a mandare posta lo fai
in un punto solo e lasci eventuali altri domini invariati.
Saluti.


Cosa intendi? Quale configurazione?
Quella del MTA (eg. sendmail, postfix...) che di default non hanno
meccanismi per gestire SPF.
Saluti.


 meccanismi per gestire SPF.
Sì va beh, io voglio fornire informazioni agli smtp server di buona 
volontà che interpellano il record spf. Per gli altri, amen.

 E' sempre cosi'. Comuque se hai paura di non risalire al server
Il record MX, da RFC, contiene sempre un host name e mai un ip?
Se è così, vado tranquillo specificando solo mx nella stringa SPF. E' 
evidente che se è prevista la voce mx, e il record mx da RFC può 
contenere solo un host name e mai un ip, allora chi interpreta il record 
spf esiguirà la risoluzione dell'host name trovato.
Altrimenti il controllo sulla voce mx fallirebbe sempre da parte di chi 
interpreta il record spf contenente tale voce, il che non è credibile.
Sempre, appunto, se è corretto che il record MX contenga sempre e solo 
un dominio tipo 
qualcosa.qualcosaltro.it
 e mai 1.2.3.4



E allora il numero di email che ricevi da spammer che si spacciano per
i tuoi utenti non scendera' di una virgola.  :)


 i tuoi utenti non scendera' di una virgola.  :)
Difficile che scendano visto che sono 0 a seguito di una corretta 
configurazione dell'smtp server.

un dominio tipo 
qualcosa.qualcosaltro.it
 e mai 1.2.3.4
Ho scritto di fretta senza chiarire quello che volevo dire.
Per quella che e' la mia esperienza i record li ho sempre visti cosi
(poi uno se li puo' definire come gli pare, usare CNAME e via
dicendo):
@	IN	SOA	bla bla bla
@	IN	NS	
nameserver1.it
.
@	IN	NS	
nameserver2.it
.
@	IN	MX	5 mail
@	IN	A	1.2.3.4
www	IN	A	1.2.3.4
mail	IN	A	1.2.3.5
Quando controlli un record SPF e' irrilevante cosa c'e' specificato
come record MX tanto alla fine deve sempre ridurre tutto a un
indirizzo IP per poter fare a grandi linee questo:
Con che IP si presenta questo tizio che vuole mandare posta?
Quale IP e' autorizzato a mandare posta quando il tizio di cui sopra
si presenta come HELO 
vattelappesca.it
 o From:
ute...@vattelappesca.it
?
Gli IP coindidono?
Si allora e' tutto a posto.
No, allora c'e' qualcosa che non va.


configurazione dell'smtp server.
Quindi le email tipo: From: 
ute...@tuodominio.it
 To:
ute...@tuodominio.it
 le fai passare solo se provengono da un range di
IP specifico (eg. LAN)?



Perchè -per servire a qualcosa- il resto del mondo dovrebbe onorare il
tuo record SPF.
E la percentuale di mailserver che lo fa, lì fuori, è suppergiù del lo
0.1%, IMHO.


 mx è indicato un dominio di terzo livello.
Il record MX *deve* puntare a un record A (o AAAA).

 Il record MX, da RFC, contiene sempre un host name e mai un ip?
Un record A (o AAAA), non un hostname, genericamente, visto che
un hostname potrebbe essere in realtà un CNAME.

 IP specifico (eg. LAN)?
Viene fatto il relay di ciň che ha From: 
ute...@miodominio.it
 solo se 
arriva da localhost o da connessione smtp autenticata.

 0.1%, IMHO.
Un po' triste, perche' IMHO sarebbe stato un buon strumento...
bye G.L.
-- 
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 0.1%, IMHO.
se in quel 0.1% includi live/hotmail, gmail, yahoo, gmx ed altri beh,
allora mi sta anche bene quella percentuale <grin>

bye G.L.
Ho scritto ad una piccola banca oggetto di email di phishing
suggerendo loro di implementare SPF, per via della scarsa invasivita'
e della facilita' di implementazione, invece di scrivere pagine di
consigli che lasciano il tempo che trovano. 
Secondo te come mi hanno risposto? :|


 Secondo te come mi hanno risposto? :|
Come si chiama questa "piccola banca" ?
-- 
  Daniele Orlandi						つづく

 Secondo te come mi hanno risposto? :|
Perche', hanno addirittura risposto?
-- 
Cio' che si vede, e'.



Una delle del gruppo carige se non ricordo male (o una delle altre 7
per le quali ricevo mail di phishing).
Hanno risposto in differita con un messaggio automatico dove mi
invitavano a legger le pagine relative alla sicurezza e che loro non
richiedono mai password via email e bla bla bla...
Saluti.


 richiedono mai password via email e bla bla bla...
Hai per caso scritto anche a 
bps.it
 ?
-- 
  Daniele Orlandi						つづく


Se non è usato per il reject ma solo per scoring, il record SPF *a te*
non serve a una fava, a meno che tu non sia una banca o una simile
entità cui la falsificazione da parte di un terzo causa danni (phishing
e simili).
E nè Hotmail nè Gmail nè Yahoo rigettano su hard-fail SPF, AFAIK.
Sei una banca?


 E nè Hotmail nè Gmail nè Yahoo rigettano su hard-fail SPF, AFAIK.
Poste.it va in deferral sul soft-fail, mi pare.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

> Sei una banca?
Non esattamente, ma, volendo, potremmo
anche accordarci <eg>
Seriamente, afaik ESISTONO entità (e
neanche da ridere) che fanno reject su SPF
hardfail ... incluso gmx ... ma non solo
poi, è ovvio, uno è libero di decidere come
farsi del male; puoi rispettare la volontà di chi
ha pubblicato un dato record SPF o non farlo
nessuno ti obbliga, è come con le DNSBL,
nessuno ti obbliga ad usarle per rifiutare le
emails provenienti da determinati hosts :P

Hai per caso scritto anche a 
bps.it
 ?
bps.it
 fa impiantistica. :)
Se intendevi monte dei paschi non gli ho scritto.


 
bps.it
 fa impiantistica. :)
Eh lo so, è un mio cliente.
C'è un tizio che ha scritto al cliente per un phishing che aveva come from 
@
bps.it
 spacciandosi per Banca Popolare di Sondrio e citava proprio SPF.
Non eri tu, vero?
-- 
  Daniele Orlandi						つづく

Non eri tu, vero?
No, io ho scritto a una banca e mi ha risposto una banca e non ho
scritto ad altri a proposito di SPF.
L'unico motivo per il quale non sono dicuro di che banca si trattasse
e' che una volta ricevuta e letta la risposta, ho cancellato le due
mail mentre li mandavo mentalmente a cagare. :)
Saluti.




mail mentre li mandavo mentalmente a cagare. :)
Come non detto, recuperata da cestino, non una banca del gruppo
carige, ma proprio 
carige.it
:
segnalazio...@carige.it
Da un banca un record SPF me lo aspetterei, oltre alle (inutili)
pagine che spiegano cos'e' il phishing.


 Se intendevi monte dei paschi non gli ho scritto.
Se hai da segnalare qualcosa in Mps puoi scrivermi in mail?

 scritto ad altri a proposito di SPF.
Okay, fa nulla, è che a quello che mi ha scritto avevo un paio di cosine da 
dire.
Che SPF l'ho valutato ma non posso abilitarlo in hard-fail perché rompe il 
forwarding e in soft-fail è inutile.
E poi gli avrei detto che proporsi come nuovo fornitore è da sfigati.
Per inciso, SPF lo uso io da anni e non ha mai impedito che mi arrivassero 
valangate di backscatter.
Ciao,
-- 
  Daniele Orlandi						つづく

 mi arrivassero valangate di backscatter.
SPF non è pensato per arginare il backscatter, lo scopo di
SPF è semplicemente quello di permettere ad un dato dominio
di specificare quali hosts siano "autorizzati" all'invio di email per
conto del dominio stesso; per quanto riguarda il backscatter
esistono altri meccanismi, come ad esempio BATV o VERP

 Devi usare anche SRS 
http://www.openspf.org/SRS
Non di usarlo tu.
Devi solo farlo usare al *resto del mondo*.


 conto del dominio stesso
Già... ma alla fine quale è l'utilità effettiva?
Non posso usarlo per filtrare per via del forwarding.
Non mi protegge dal backscatter se lo pubblico io.
Non serve nemmeno come whitelisting.
Aggiunge problemi perché il cliente deve essere cosciente della policy.
Che me ne fo?
-- 
  Daniele Orlandi						つづく

 Devi solo farlo usare al *resto del mondo*.
Beh... se sei TU a fare forwarding... <g>


Se sei tu a fare il forwarding il problema non si pone: sui tuoi sistemi
hai controllo e fai quel che vuoi.
Quel su cui non hai alcun controllo è ciò che fa il resto del mondo, ed
è la ragione per cui SPF ha avuto il successo (risibile) che ha avuto.


valangate di backscatter.
Io lo trovo utile quando hai N domini in hosting e usi SPF per fare il
controllo su te stesso.
In questo caso elimini molta fuffa da chi si spaccia per un tuo utente
e manda mail non autenticato.


Se hai da segnalare qualcosa in Mps puoi scrivermi in mail?
Se dovessi ricevere phishing relativo a MPS te lo giro.
Per adesso vedo:
BCC Credito Cooperativo
Cariparma Gruppo
Cassa Risparmio Genova Savona
Cassa di Risparmio di Ferrara
Gruppo Banca Carige
Gruppo Bancario Mediolanum
Gruppo Casse Risparmio Genova Savona Imperia
simplybank
Con questi subject (servissero a qualcuno):
Securecall, il nuovo sistema di sicurezza
Effettuare l'aggiornamento dei dati
Comunicazioni dalla tua banca
Le BCC offrono un'operativita bancaria completa
La sicurezza degli account online
Un nuovo documento di rendicontazione
Rendicontazione on line
Problema con il tuo conto
Messaggio Importante**
Comunicazione di servizio per i clienti Banca Mediolanum
L'utente e stato bloccato
AVVERTENZE IMPORTANTI
Cassa Risparmio Genova Savona
Comunicazione di servizio per i clienti Banca Carige
Nuova versione di Banca Carige
E gli evergreen, cartasi e poste italiane:
Verifica il tuo conto
riaddebito e storno 203,00
Saluti.


 Se dovessi ricevere phishing relativo a MPS te lo giro.
OK ti ringrazio, lo girerň a chi di dovere...

> è la ragione per cui SPF ha avuto il successo (risibile) che ha avuto.
http://www.ceas.cc/2006/19.pdf
http://dns.measurement-factory.com/surveys/200910.html
certo, se si bada alle percentuali il tasso di adozione sembra
essere basso, se però guardi al volume di email trattato dai
domini che pubblicano/usano SPF il discorso cambia
http://spf-all.com/stats.html

 domini che pubblicano/usano SPF il discorso cambia
qualche esempio
http://spf-all.com/query.py?domain=gmx.com
http://www.senderbase.org/senderbase_queries/detaildomain?search_string=gmx.com
http://spf-all.com/query.py?domain=facebook.com
http://www.senderbase.org/senderbase_queries/detaildomain?search_string=facebook.com


Non se stai sul pezzo e vedi tutti i giorni di chi sono oltre il 90% dei
domini che usano SPF in un flusso postale generico, come quello visto da
un provider: snowshoe spammers.


 snowshoe spammers.
Al momento non sono sul pezzo :) in qualsiasi caso, non
vedo utilità pratica nell'uso (pubblicazione) di SPF nel caso
di snowshoe; dopotutto SPF *non* è un metodo per il
whitelisting

 whitelisting
Eppure tutti i motori in circolazione assegnano un punteggo positivo
(sia pur molto basso, proprio per quanto sopra) a mail che matchino
record SPF.
Così come lo assegnano a mail che riportino signature DKIM corretta.
Quindi, di nuovo:
- o sei un soggetto ben conosciuto che è soggetto a falsificazione e
riceve un danno specifico da tale falsificazione per via di fenomeni di
phishing (Banche, sì. Ma anche Facebook e Hotmail o Gmail)
- oppure con i record SPF te ne fai davvero nulla
Entrambi i meccanismi (DKIM soprattutto, visto che non soffre dei
problemi da forwading di SPF) sono invece utili quando associati a
meccanismi di reputation domain-based, dato che forniscono una
correlazione tra la singola mail e il dominio da cui proviene la stessa
senza doversi preoccupare della eventuale falsificazione di quest'ultimo.
Presi da sè, viceversa, non servono praticamente a nulla.


 Presi da sè, viceversa, non servono praticamente a nulla.
Servono a colmare una lacuna :) non c'è altrimenti modo di
specificare se un determinato host sia autorizzato o meno
all'invio di emails per conto di un dato dominio

ed una utilità
Sono daccordo, basta pensare a un provider che offre hosting e mail ha
tutti i clienti che mandano posta da fuori.
Con un record SPF su tutti i domini che ha in hosting costringe i
clienti a usare la posta autenticata e non si deve inventare alchimie
strane per evitare tutte le email col campo from falsificato se usi
postfix (che consegna sempre se il destinatario esiste e il server e'
l'ultimo hop della catena).
Poi se lo usassero anche le banche, chi ha un MTA configurato per
controllare SPF si risparmierebbe tonnellate di email di phishing.


 tutti i clienti che mandano posta da fuori.
Permetti, ma l'utilizzo che disegni è parte della mia definizione della
mia definizione di "inutile".
Se l'obiettivo è quello di inibire sulle *tue* macchine l'ingresso di
posta che falsifica i *tuoi* utenti, non è certo necessario SPF: tutto è
sotto il tuo controllo e fai quello che vuoi.
Il fatto di mettere quelle informazioni su DNS anzichè nella
configurazione dell'MTA o su database è al limite comodo, ma non è
quello per cui il meccanismo dovrebbe essere pensato.
Parliamo dell'efficacia di pubblicare record SPF quando trattiamo
dell'effetto ottenuto su sistemi *remoti*.


 all'invio di emails per conto di un dato dominio
DKIM colma la stessa lacuna (insieme a molte altre), ma almeno non rompe
il forwarding...
[1] che è quello proveniente *davvero* da Hotmail, Gmail etc e quindi
dotato di buona reputation e per il quale quindi i meccanismi di
reputation non sono d'aiuto; insieme a quello proveniente da snowshoe,
dove il dominio non ha alcuna reputation (dato che il senso del
meccanismo è proprio quello di non averla).


dell'effetto ottenuto su sistemi *remoti*.
A volte usare SPF anziche' fare contorsionismi nella configurazione
dell'MTA e' piu' semplice, sull'impatto sui server remoti anche se ne
potrebbe parlare.
Il punto comunque e' che indipendentemente da come si chiama il
meccanismo se nessuno lo implementa per pigrizia pensando che "tanto
lo fara' qualcun altro", non si va molto lontani.


CUT
------=_NextPart_001_5C94_6AD226F0.400046C7--


 Spin me la rimbalza come SPAM se te la mando come allegato...
In casi come questi la procedura standard è zippare il
file proteggendolo con una password, mandare lo zip come
allegato e mettere la password nel corpo del messaggio.
Bye, G.

allegato e mettere la password nel corpo del messaggio.
Tale e quale alle email con virus zippato?


 Tale e quale alle email con virus zippato?
Come il virus albanese, identico, ma scritto in italiano migliore.

 il forwarding...
Skull, dissento.
DKIM non colma le lacune che colma SPF.
DKIM autentica la mail, header e body, contro eventuali falsificazioni.
SPF/SRS servono per restringere il campo degli MTA mittenti per un dato 
dominio.
VANTAGGI:
Entrambi possono servire per fare scoring.
Entrambi possono essere utili per rigettare email.
Entrambi sono strumenti utili contro lo spam e il phishing.
SVANTAGGI:
SPF ha lo svantaggio di SRS perchè, checchè se ne dica, SPF Senza SRS non 
ha molto senso (lo ha nella maggior parte degli ambiti, ma non in tutti), 
e questo è il meno (leggasi dopo).
Entrambi NON sono adottati su vasta scala, né dai piccoli, che si 
gioverebbero dell'applicazione per rigettare mail, né dai grandi 
(provider, banche e simili) che, a parte alcuni colossi (non grandi, ma 
colossi) si gioverebbero di diminuire lo spam che sembra originare dai 
loro utenti.
E chi lo usa spesso lo usa in modalità non esclusiva [1], in testing [2] 
o non usa una ADSP[3] diversa da Unknown,  il che lo rende praticamente 
inutile dal 95% dei punti di vista.
UTILITA':
troverei entrambi i sistemi MOLTO utili in teoria per fare scoring (DKIM) 
o rigettare, ma in pratica pochi li usano correttamente.
Di fatto, però, SPF/SRS è più criticato per un semplicissimo motivo:
l'MTA più diffuso in ambito opensource, ovvero postfix, utilizza SRS solo 
con delle patch piuttosto accrocchiate che ne scoraggiano l'utilizzo. 
Questo è il *vero* motivo per cui SRS in accoppiata con SPF non viene 
utilizzato e per cui il mondo crede che SPF sia uno schifo perchè 
richiede SRS.
Max
[1] notare ?all
_
spf.google.com
 descriptive text "v=spf1 [CUT] ?all"
[2] notare t=Y per testing
gamma._
domainkey.gmail.com
  TXT "k=rsa; t=y; p=MI..."
[3] NXDOMAIN
_adsp._domainkey.gmail.coms does not exist, try again

 (provider, banche e simili) che, a parte alcuni colossi (non grandi,
il motivo, parlando fuori dai denti è semplice - i costi; sebbene sembri
facile adottare SPF/DKIM, questa adozione significa effettuare una
revisione accurata della propria rete controllando e mappando tutti i
punti di emissione e risolvendo come si deve (e non con dei "cerotti")
le varie problematiche e quanto sopra implica tempi e costi e va contro
la filosofia (adottata -purtroppo- da moltissimi) del "fino a che funziona
non si tocca" (che ha avuto varie conseguenze, vedasi ad esempio il
"botto" relativo alla vuln SSH o quello relativo al DNS poisoning :-P)
Per farla breve, l'intera infrastuttura viene mantenuta usando principi
di mantenimento dello "status quo" e gli aggiornamenti vengono fatti
solo se indispensabili, questo ovviamente signifca che fino a che le
cose funzionano, nessuno tocca nulla; certo, le crepe si allargano,
visto che l'informatica si evolve molto rapidamente, ma fino a che i
problemi non toccano il portafoglio, nessuno si preoccupa di mettere
rimedio agli stessi
Il risultato netto è quello che vediamo; nella fattispecie un gioco al
"whack a mole" nei confronti di spam e malware ed il tentativo (inutile)
di "arginare" quanto possibile; ovvio che tutto ciò ha un ritorno economico,
quindi, sino a che non ci sarà la necessità di spendere dei soldi allo
scopo di adeguare reti ed infrastutture e, sino a quando tale inadeguatezza
PORTERA' dei soldi, nessuno alzerà un dito al proposito
Del resto, se spam, malware e robaccia varia mi fanno guadagnare
soldoni vendendo servizi... perchè implementare una soluzione reale
che mi costerebbe soldi e arresterebbe tale guadagno :-P ?

 che mi costerebbe soldi e arresterebbe tale guadagno :-P ?
Ah.. e NON mi riferisco solo ad SPF/DKIM

 il motivo, parlando fuori dai denti è semplice - i costi; sebbene sembri
Tu dimentichi anche l'incompetenza.
La fuori, normalmente, gli spammer non si confrontano con sistemisti 
competenti, ma con incapaci che di antispam ci capiscono poco.
Ovviamente ci sono le dovute eccezioni e nella categoria sopra citata di 
solito non rientrano sistemisi che partecipano a questo NG.

che mi costerebbe soldi e arresterebbe tale guadagno :-P ?
...è vero che in patria (e non solo) tanti ragionano a coglione, ma non e'
quello li' sopra che quoto, il ragionamento da quadrumane; il ragionamento
che vedo fare è invece circa quell'altro che citavi:
	In fondo si', spam e malware ci fanno PERDERE un po' di soldi,
	ma poco, perché lo ricarichiamo sul cliente finale, come fanno
	tutti, e quindi neanche perdiamo mercato.
	E poi, una soluzione seria invece ci COSTEREBBE quattrini... e
	poi se non funziona? Me lo garantisce lei che funziona? Finora
	s'e' sempre fatto cosi'... e poi la mail non e' mica il nostro
	core business, anzi io decentralizzerei, e se ci appoggiassimo
	a Google? E se smettessimo di offrire i servizi di mail? Tanto
	se uno vuole la mail se la fa gratuita da qualche parte...
...o dimmi un po' se non te l'hanno fatto anche a te, e scommetto, qualche
decina di volte?
Leonardo polemico (devo far mettere meno spezie nel lampredotto)
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

 lo fara' qualcun altro", non si va molto lontani.
Non č affatto questione di pigrizia.
E' proprio questione di causare disservizio agli utenti in presenza di
alcune specifiche situazioni (forwarding) che sono tutt'altro che rare,
soprattutto se non gestisci il mailserver di casa tua ma sistemi di ISP
che forniscono servizio a decine di migliaia di utenti.
E' quella, la ragione per la quale SPF č destinato a fallire. Mica la
pigrizia.


 Spin me la rimbalza come SPAM se te la mando come allegato...
Modestamente...


 che mi costerebbe soldi e arresterebbe tale guadagno :-P ?
Questa è una affermazione che toglie qualsiasi dubbio alla credibilità
(residua) che possa riporre mediamente nelle tue opinioni...


 richiede SRS.
IMHO, il problema è *parecchio* distante da quel che dipingi.
[1] DBL, URIBL e SURBL *sono* indubbiamente un mecanismo di
domain-reputation, ma non sono pensati per questo utilizzo.


Modestamente...
Mica me ne sto lamentando. :)


 IMHO, il problema è *parecchio* distante da quel che dipingi.
Quanto sopra è sicuramente parte del problema.
Guarda, posso concordare con te se il "parecchio distante" lo traduci  
schematicamente così:
- DKIM e SPF/SRS non sono sufficienti ad arginare lo spam, ma possono 
aiutare a farlo
- DKIM e SPF/SRS godono delle stesse applicazioni, superficiali ed 
inutili e presi a sè stanti, non servono a nulla
- DKIM e SPF/SRS (quest'ultimo soprattutto) godono di una letteratura 
alquanto scarna il che obbliga la maggior parte dei sistemisti ad 
ignorarli o ad utilizzarli male, così come sono scarne le implementazioni 
software disponibili (opensource o a pago)
- L'Opensource non aiuta all'implementazione di tali sistemi 
(probabilmente perchè reputati poco utili).
In conclusione, secondo me, DKIM e SPF/SRS sono strumenti molto molto 
utili per combattere lo spam ma vanno a far parte dell'arsenale del 
sistemista antispam che è molto ben più ampio (RBL, URIBL, Script vari, 
analisi statistica etccc) tant'è che, viste tutte le altre armi a 
disposizione, ne possono fare a meno.
Se, al contrario, esistesse la letteratura e le implementazioni software 
adeguate, anche il sistemista wannabe potrebbe utilizzarle ed 
implementarle in maniera semplice.
Non dimenticarti di quelli che su icol.sys se ne sbucano con domande 
alquanto fantasiose sulle configurazioni degli MTA, dimostrando quanta 
ignoranza c'è in giro su questi argomenti.
Max

 forwarding- non retrocompatibili, fallendo aperto.
Una nota a margine ai miei Rants.
Rispettandoti e stimandoti molto come sistemista e come antispammista e 
considerando pure la reputazione e la qualità del tuo employer, sono 
sicuro al 100% che SPF tu lo useresti senza il minimo problema se avessi 
un modo facile, veloce e trasparente per implementare SRS (che, come 
implementazione, teoricamente, è banale).
Ovvero: Se Postfix gestisse i forward con SRS, sicuramente tu lo avresti 
implementato.
E gestirlo è *veramente* facile, è postfix che è limitato !!

 Leonardo polemico (devo far mettere meno spezie nel lampredotto)
Why ?
Sei pure tu fiorentino ?

Sei pure tu fiorentino ?
Certo. La 'un mi fo manca' nulla :-)
Leonardo


 
Risposte in ordine sparso.
Utilizzo in modalità "check":
- io SPF lo uso in check per alcuni limitati scopi, dove mi è utile (es:
domini come 
poste.it
, molto soggetti a phishing e pubblicanti record SPF
in hard-fail).
- non lo uso "urbi et orbi" in hardfail, perchè per chi come me gestisce
N (>1K) domini per M*N utenti, SPF crea più problemi di quanti ne
risolva, e questo me lo dice l'esperienza diretta, non una statistica
parziale o una posizione presa aprioristicamente
- lo uso come parte del motore di scoring, associato a meccanismi
interni di domain-reputation. In realtà, lo uso più per beccare
snowshoers che altro (il che è tutto un dire)
Pubblicazione record SPF:
- pubblico ed effettuo statistica su alcuni domini "campione", sia di
record in hard-fail che in soft-fail, principalmente per finalità
statistiche
- quand'anche volssi usarlo sui miei clienti (che hanno i *loro* domini)
che hanno le *mailbox* da me, si pone il problema di dover seguire il
cliente nella parte di sua competenza: dal corretto include del record
SPF da me mantenuto sul *suo* dominio di posta, all corretto utilizzo in
termini di policies da parte dei suoi utenti (i titolari delle singole
mailbox), che devono usare i *miei* MSA e non quelli del suo ISP di
connessione ("ma me l'hanno detto quando ho telefonato a $ISP, di usare
questo SMTP qui")
- se volessi usarlo per i clienti che hanno solamente mail-filtering
(aka "mail relay filtrato) da me, avrei, oltre ai problemi di cui sopra
anche la necessità di star dietro alle cazzate che combina il
"sistemista" sul mailserver interno, oltre a quel che fanno i singoli utenti
- nei due casi precedenti, avverrebbe poi che alla prima mail filtrata
*giustamente* da SPF, gli utenti iniziano a whitelistare a prescindere
gli appartenenti al loro stesso dominio, perchè "il sistema sennò li
filtra per sbaglio", con i risultati esilaranti che si possono
immaginare (citato anche qui in passato): lo fanno già ora perchè "non
si sa mai", figurati poi quando capita davvero...
- SRS: il forwarding, sui miei sistemi, non lo fa postfix, ma degli
script in perl home-made, pressochè da sempre. La versione "SRS" di tale
script la ho pronta da anni (da quando implementai il sistema attuale,
di fatto, circa 4-5 anni fa). Salvo un breve periodo di test, non è mai
entrata in fase "production", per una ragione assai semplice: modificare
la gestione dei forward significa (per me) anche riscrivere una discreta
quantità di SW al contorno. Se è opportuno, lo si fa senza problemi. Ma
farlo "per il gusto di", per soddisfare una implementazione destinata a
morire e a non prendere piede, significa buttare via il tempo.
E SPF/SRS non ha mai superato la soglia oltre la quale ne valesse
davvero la pena.
DKIM: per quel poco (o nulla) che vuol dire, lo uso (anche contornato da
record ADSP) in firma per alcuni domini:
zarathustra:~ skull$ dig txt +short mail._
domainkey.staff.spin.it
"v=DKIM1\; g=*\; k=rsa\;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFloS8qyF4fmQlh432hg+cjTLMGKt+u2q9iDEhpxkanJEMkPPX7wMJsw0NQMc5xWgbUWYEJPAdlh2g/h+6cr6ETLnKvwvioSHrb6r95+vFWFaQAe/emHJIh8WkchV/rXqvMhQdk62zSWnpJs2N6c0uA3YMc2BIn5SICoVeI6JS+wIDAQAB"
zarathustra:~ skull$ dig txt +short _adsp._
domainkey.staff.spin.it
"dkim=all\; t=s"
Ma -di nuovo- è un utilizzo velleitario, dato che in assenza di
meccanismi di reputation non serve a nulla.
Almeno -a differenza di SPF- non causa problemi collaterali.


 ignoranza c'è in giro su questi argomenti.
Ok.
Però a tutt'oggi, credo che sì e no lo 0.2% delle reti *aziendali* in
Italia effettui outbound filtering della porta 25. Nonostante sia la
base per il controllo delle problematiche di spam dalla propria rete.
Una penetrazione di queste prassi che passasse dallo 0.2% al 20% (sempre
limitato alle reti aziendali, non alla LAN della casalinga di Voghera)
causerebbe un calo dello spam ben maggiore di una adozione 100%
worldwide di SPF/SRS e DKIM in contemporanea.
Sinceramente, inviterei a fare un po' di proselitismo nel cercare di
inculcare prima di tutto *queste* misure ai postmaster in questione.
Altro che usare SRS su postfix.



La superiorità dell'intelligenza del fiorentino rispetto all'italiano medio 
è cosa risaputa e provata da tempo
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu

 medio è cosa risaputa e provata da tempo
Toh, un altro... proprio quello che mi serviva.
Perchè noi 3 non ce ne andiamo un giorno a cena ?
Max

 inculcare prima di tutto *queste* misure ai postmaster in questione.
Si ma anche sul proselitismo avrei molti altri dubbi.
Il proselitismo sulle best practices è cosa buona  e giusta, ma una best 
practice come chiudere la 25 in ooutbound sarebbe non necessario se ci 
fosse un pò di cultura.
Non bisogna quindi fare solo proselitismo, bisognerebbe diffondere la 
cultura dell'antispam in generale.
Qui sorge però un altro problema: chi l'antispam lo fa professionalmente 
e ci guadagna, di solito è molto geloso delle sue tecnologie e dei suoi 
metodi. Oltre alle RBL e a qualche milter, poco si trova in giro sulle 
tecniche antispam, sia a livello SW che a livello documentale.
Mi sorge in mente un esempio che non ha a che fare con l'antispam in 
maniera tecnica ma con lo spam e l'abuse in generale: su questo NG c'è un 
Idiotax che si vanta di fare denunce all'autorità garante a go-go ma si 
rifiuta di fornire gli esempi e le modalità con cui porta avanti le sue 
segnalazioni. Ok, quella è idiozia, non gelosia delle proprie tecnologie, 
ma questa gente esiste.
Max

è cosa risaputa e provata da tempo
Ho spesso il sospetto di essere un controesempio, ma è discorso doloroso
che rimando altrove... non voglio unirmi al gruppo di chi tuona contro i
giudici komunisti, poi rischio di beccarmi tre voti anch'io.


 qualche decina di volte?
heh... been there etc... vogliono tutti la "silver bullet" :P

 opinioni...
Libero di pensarla come vuoi, ci mancherebbe, mi resta solo
il dubbio che tu abbia travisato il senso del mio post

 che tu abbia travisato il senso del mio post
Penso anche io che Skull abbia male interpretato.
Purtroppo lo spam esisterà sempre, perchè la pubblicità (legittima o 
meno) è l'anima del commercio.
Però lo spam è l'anima de 'li mortacci loro :-D

heh... been there etc... vogliono tutti la "silver bullet" :P
Dé, esistesse la formula del pimpirimpì, il cliente pensa mica che siamo
tutti stupidi, o disonesti, a non adottarla?
(E' una domanda retorica! La risposta è storicamente "CERRRTO!" :-( )
Leonardo a volte sconfortato


 Leonardo a volte sconfortato
solo "a volte" :) ?

 è cosa risaputa e provata da tempo
Anche modestia e simpatia, eh. 
-- 
s.
What's the difference between a priest and acne?
Acne waits 'til you're a teen to come on your face.
 


(cfr. domanda B.3) della mia FAQ)
ben visibili a tutti e tu, Citrosodina, che certamente non sei un
niubbo e sai usare un browser, non sei certo un vigliacco bugiardo,
no?
PS: Citrosodina, ma a te l'avvocato degli spammer e dei bambini di
bofhland, quella carogna calunniatrice di Perugia, non te l'ha
notificato l'ordine di tacere e di piantarla con queste sbroccate
gratuite, emanato intorno alla metà di gennaio? :-O
-- 
Lex Tutor
L'Asilo Infantile di Bofhland® è un argomento che sarà oggetto
di un libro di prossima pubblicazione, quindi sto discutendo
di una questione che mi interessa per finalità di ricerca.

 No, però ho trovato parecchie fatte di cinniàle ]:-D
Attenzione, quando vai in certi posti:
http://bari.repubblica.it/cronaca/2010/08/23/news/i_ragazzi_hanno_visto_il_cacciatore_killer-6447575/
Bye, G. 

 Anche modestia e simpatia, eh.
Quelle son sottintese


 tecniche antispam, sia a livello SW che a livello documentale.
Anche su questo, un tempo sarei stato d'accordo, ma il tempo mi ha
disilluso.
Per le stesse ragioni già dette precedentemente: il sistemista medio
vuole la soluzione che si configura in 5 minuti e ci si dimentica.
Il mondo reale, però, è più complicato, e parecchie "soluzioni"
richiedono comprensione dei dettagli, tuning, considerazioni,
progettazione infrastrutturale, etc.
Non è roba che si passa con quattro link.
Soprattutto non a chi non ha la voglia (e/o, spesso, nemmeno il 5% del
tempo necessario) per comprendere cosa ha per le mani e come trattarlo.
Anche perchè alcune cose richiedono mesi/anni di dimestichezza con il
tema, prima di essere realmente comprese.
Domanda a Furio per quanto tempo ho combinato cazzate sotto la sua
supervisione, prima di divenir "degno" di autonomia... :-\
IMHO (o, almeno, per quanto mi riguarda) la ragione sostanziale per cui
trovi in giro solo informazioni su "RBL e qualche milter" è quella, in
primis...
Per qualsiasi cosa vada oltre quello (e già anche per quello, spesso) lo
scoglio relativo alla comunicazione è piuttosto critico.
Se poi qualcuno (LUG?) vuole organizzare "sedute di formazione" in
quest'ambito, di certo non mi tiro indietro.
Ma come hai visto quando fece qualcosa di simile il LUG lì a Firenze, se
ne vanno 2 ore abbondanti già per una introduzione senza nulla di tecnico...
