Newsgroup: it.news.net-abuse
Titolo: Richiesta di chiarimento SPF

Ciao,
alcune precisazioni:
- il record TXT va creato nella zona del dominio, in ogni caso mai
nella zona dei reverse?
- finchè non diverrà uno standard (o uno standard de facto), chi
abilita il controllo SPF (o altri) non rischia di causare + problemi
che vantaggi?
Grazie
JD

 problemi che vantaggi?
dipende; nel caso di presenza del record SPF per un dato
dominio chi abilita il check non fa altro che "rispettare" quello
che è stato pubblicato per quel dominio; nel caso di assenza
del record si utilizzerà un "default accettabile" e nel caso in
cui un dominio usi un SPF con softfail eventuali hosts che
ricadano nel "softfail" dovrebbero semplicemente ricevere
uno scoring più elevato.. non vedo grossi problemi dal punto
di vista del check; semmai ci potrebbero essere per quanto
riguarda l'implementazione anche perchè in alcuni casi sarebbe
necessario ricorrere ad SRS per far funzionare il tutto; resta il
fatto che SPF potrebbe risolvere molte problematiche (es. quella
del phishing) a costo praticamente nullo

 del phishing) a costo praticamente nullo
Il problema con l'accoppiata SPF/SRS è che anche in casi in cui...
- il mittente rispetta i propri record SPF
- il destinatario applica correttamente i check
...capitano ugualmente problemi perchè *qualcuno* in mezzo non fa uso di
SRS, e quindi è *impossibile* sia per il mittente che per il
destinatario garantire un check error-proof.
Il che -IMHO- è tutt'altro che un problema di secondo piano...
-- 
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.

 Il che -IMHO- è tutt'altro che un problema di secondo piano...
Ok.. perfettamente corretto; ma torniamo per un momento al
discorso che facevo nell'altro post relativo alle banche e/o
cmq ad istituzioni simili; nel 90% di questi casi il problema
del "qualcuno in mezzo" non esiste; ora, considerando che
la pubblicazione di un record SPF avrebbe costo zero ed
allo stesso tempo permetterebbe di abbattere in maniera
drastica il phishing .. perchè no
tornando all'argomento di questo thread; hai ragione; però
per certe realtà in cui i mailservers sono sotto il diretto controllo
dell'admin.. non vedo il motivo di non pubblicare i records SPF
di nuovo.. costano zero e non fanno male; certo; esistono delle
eccezioni ma sono appunto ... eccezioni :)

 - il destinatario applica correttamente i check
Cosa ne pensi di questo approccio leggermente diverso di SPF, mi 
spiego. 
Notoriamente vi sono Nazioni identificabili dai loro Ip (io uso maxMind 
per fare questo) che sono note fonte di spam. Parlo di Cina, Korea, 
Russia ad esempio.
Il mio approccio è stato questo: se questi ip non sono in whitelist 
e/o dominio whitelistato, non sono in nessuna BL, verifico allora se 
hanno un SPF valido, se si passano, altrimenti droppo con 554. Questo 
non esclude successivi controlli in fase DATA, mi riferisco 
semplicemente al controllo in fase di connessione al server smtp.
Fino a poco tempo fa, semplicemente droppavo tutta la Cina ma mi sono 
reso conto che alcuni miei clienti ci lavorano e quindi era un 
approccio troppo esagerato.
-- 
Ciao, Dmitry
I've a dream... bring usenet to every family 

 drastica il phishing .. perchè no
Che son d'accordo e -cum grano salis- lo applico anche liddove utile: ad
esempio una notevole eccezione alla regola che dipingi è 
bancaintesa.it
,
che pubblica record SPF in hard-fail.
Per realtà come questa (e solo per esse) SPF è tra i check applicati
E' buono, nella misura in cui finora ha bloccato parecchi run di phishing.
Ciononostante, i suoi problemi li ha: se ad esempio un cliente ha una
mailbox da Tin (ma metteteci pure un ISP qualsiasi, è solo un esempio)
e la ridirige sulla sua mailbox da noi, vìola il record SPF.
Questo effetto collaterale è "tenuto a bada" evitando di applicare il
check SPF alle mail provenienti dagli MTA di uscita degli ISP più grossi.
Questa configurazione, però
- è prona a falsi negativi (mail di phish relayed attraverso gli ISP di
cui sopra)
- non elimina completamente le possibilità di falsi negativi (es: un
redirect su un ISP "secondario", o altro)
- richiede un overhead amministrativo che non tutti -forse- si possono
permettere, in particolare in realtà piccole
Sono eccezioni, ma sono eccezioni finchè son poche.
Se estendessi il check SPF a qualunque dominio, probabilmente
smetterebbero di essere eccezioni, almeno su basi di utenti
sufficientemente ampie...


 sufficientemente ampie...
Beh.. gestisco alcuni mailservers ed utilizzo check SPF su alcuni di questi
per tutta la mail in ingresso e sinceramente non ho visto tutti questi
problemi;
certo; si tratta di mailservers "aziendali" e con un basso volume di
traffico (ad
esempio uno dei servers gestisce in media di 3000 messaggi al giorno) però
sinceramente NON ho riscontrato  problemi nell'uso di SPF
ciao

 esempio uno dei servers gestisce in media di 3000 messaggi al giorno)
Aumenta di un paio d'ordini di grandezza e i probblemi spuntano...


 Aumenta di un paio d'ordini di grandezza e i probblemi spuntano...
beh è uno dei servers (sono una ventina) ed uno di quelli a traffico basso
con questo NON voglio paragonare le problematiche di gestione di tali
servers con quelle relative alla gestione di servers "pubblici" ma se
parliamo di "mole di messaggi" beh.. diciamo che sono ai livelli della
"massa critica" di cui parli e sinceramente non vedo grossi problemi
anche perchè come ho scritto si tratta di servers "aziendali" e non di
mailservers "pubblici" quindi le problematiche sono in parte diverse
e secondo me.. minori (da certi punti di vista)
ciao

 hanno un SPF valido, se si passano, altrimenti droppo con 554.
SPF non è più diffuso in Cina che da noi, il tuo approccio non è altro che
una whitelist di pochissimo allargata. Se sei relativamente certo di avere
in wl i contatti che interessano ai tuoi clienti va bene, altrimenti il
rischio di falsi è altissimo.

Il Cat wrote:

si, è un approccio minimale, considera che cmq i domini interessati sono cmq
in whitelist

 domini interessati sono cmq in whitelist
scusa ma .. a questo punto tanto vale utilizzare delle
bl tipo 
http://countries.nerd.dk/
 per filtrare le "nazioni"
indesiderate ed usare poi delle DNSWL come ad es.
query.bondedsender.org
, 
exemptions.ahbl.org
, 
iadb.isipp.com
e/o 
hul.habeas.com
 per "lasciar passare" gli indirizzi
"buoni" :) non dico che la cosa mi piaccia ma è meno
complicata ed alla fine il risultato è lo stesso :)

 complicata ed alla fine il risultato è lo stesso :)
immagino di si :)

 costantemente aggiornato.
conosco quel DB ma lo uso per altri scopi (anche perchè
non filtro per nazioni) ma cmq anche le zone DNS di cui sopra
sono abbastanza aggiornate e la puoi usare come normali
DNSBL .. con le dovute precauzioni ovviamente

 DNSBL .. con le dovute precauzioni ovviamente
proverò anche questo (con le dovute precauzioni)
