Newsgroup: it.news.net-abuse
Titolo: SPF e dintorni

Io non ho capito per quali ragioni o quali particolari casini il 
pupazzone la sconsigliava (ed anche qui non è chiaro se per uso 
sistematico o volonatario). L'ho provato ad implementare e oltre a 
randellare clamorosamente i phishers o l'utilizzo di domini di *grandi 
utenti* istituzionali  non, vedo che tutela anche il tuo dominio quando 
utilizzato nel from:; apparentemnte un lavoro spesso complementare a 
rbl e non sovrapposto. Morale: non ho capito un apascio io o con certe 
utenze i rischi falso son notevoli ?


Saluti.
-- 
Living in Barbaropoli
http://www.barbaropoli.com

> Il problema di SPF e' che "rompe" i forward:
No, se si usa SRS *insieme* ad SPF poi ok, SRS pone
altri problemi, per carità, anche se avendolo usato da
diverso tempo e con una miriade di indirizzi e "mailing
lists" NON ho, sino ad ora riscontrato problemi; questo
non significa che non esistano ma semplicemente che
POSSONO essere risolti


ah ecco, bravo grazie; sapevo che c'era un problema ma non mi ricordavo 
quale.
E imamgino gli SRS Forwarders sian mosche bianche vero ?
Vabbè nel mio caso il problema non si pone. whitelisting e via.

 soglia.
Dimenticavo...
NO, quella sopra è una caxxata bella e buona; se un dato dominio
pubblica un record SPF ed usa il "-all" in caso di "failure" si *deve*
fare un reject, altro che "scoring"; lo scoring lo puoi fare solo se il
dominio usa un "~all" - del resto, se chi gestisce il dominio ha deciso
che solo determinati hosts debbano essere autorizzati all'invio di
emails per conto dello stesso, credo che tale volontà vada rispettata
:)

> E immagino gli SRS Forwarders sian mosche bianche vero ?
Mica tanto, ce ne sono diversi, ad esempio per postfix o sendmail
trovi 
http://www.openspf.org/Software
 e sono solo alcuni; il problema
se cosě vogliamo chiamarlo č che SRS "rompe" il whitelisting basato
sull'indirizzo del mittente visto che questo viene modificato
In qualsiasi caso, come ho scritto e ripeto, sto usando SPF ed SRS
(ma anche DKIM se č per questo) ormai da parecchio e sinceramente
NON ho riscontrato problemi, certo, di idioti che inviano emails da un
indirizzo @
gmail.com
 passando da un server Tiscali ne esistono e
ne esisteranno sempre, ma SPF non serve a risolvere i PEBKAC :D

 emails per conto dello stesso, credo che tale volontà vada rispettata
La parte legale è pure interessante: se accetti, avendo implementato un 
filtro SPF, un e-mail taggata  * -all anzichè perlomeno * ~all 
illeggittima, e tu in primis o un tuo utente prende per buona la 
*notizia* contenuta (phishing ad esempio), ancorchè non si tratti di 
PEC che rilevanza giudiziale un tale argomento può avere ? mumble 
mumble ...

 di PEC che rilevanza giudiziale un tale argomento puņ avere ?
alla fine della fiera NON sei tu che *pubblichi* il record SPF bensģ
il mittente, quest'ultimo specifica chiaramente a chiunque utilizzi
SPF quali siano gli hosts autorizzati a spedire emails per un dato
dominio e come vadano gestite tali emails (es. reject nel caso di
SPF failure) ora, se il proprietario di un dato dominio mi dice "fai
questo con le mie emails" che autoritą dovrei avere io per non
dargli retta :) ?



Yes, possibili problemi e soluzioni sono tutte nel link riportato.




Il problema e' che tu vendi ad un'azienda sito web+servizi email e
troverai sempre il cretino che usa 
mail.alice.it
 "che gli sta piu'
comodo" invece di usare 
mail.dominio.it
 con autenticazione.
In questo caso, e a seconda di che configurazione hai, il reject secco
e' un problema causa coglionaggine utente.


 garantire che sia autentica" ... detto ciò ...
Ad esempio
;; QUESTION SECTION:
;
ibm.com
.                       IN      TXT
;; ANSWER SECTION:
ibm.com
.                600     IN      TXT     "v=spf1 -all"
il che significa che IBM specifica chiaramente che NESSUN host
è autorizzato ad inviare emails usando il dominio "
ibm.com
" e che
qualsiasi email da tale dominio *deve* essere rifiutata (reject); di
contro, se guardiamo il record pubblicato da Tiscali
;; QUESTION SECTION:
;
tiscali.it
.                    IN      TXT
;; ANSWER SECTION:
tiscali.it
.             10800   IN      TXT     "v=spf1
ip4:
213.205.33.0/24
 ip4:
213.205.37.192/27
 ip4:
195.130.225.0/24
ip4:213.205.37.169 ip4:213.205.37.171 ip4:213.205.37.172 ?all"
scopriremo che non serve assolutamente ad un tubo dato che quel
"?all" significa "neutral" in pratica "fai conto che il record SPF non
esista" <g>

 comodo" invece di usare 
mail.dominio.it
 con autenticazione.
alla quarta telefonata con relativa email con allegato il PDF che
spiega come configurare il client email per l'invio e la ricezione
della posta, chiami un killer ed elimini in problema alla radice :D

 esista" <g>
si si d'accordo la sintassi la conosco. Infatti mi chiedevo cosa 
succede legalmente se io ti dico che un host mittente non è autorizzato 
a inviare posta e tu ignorandolo (ad esempio usi un volgare score che 
non da però un punteggio definitivo pe run tag) consegnando comunque la 
posta all'utente. Metti sia una comunicazione bancaria con sender 
forgiato ad esempio.



Sai che statisticamente i coglioni sono piu' dei non coglioni?
Tipo quelli che ti chiamano perche' non gli arrivano le mail e:
A) Il mittente riceve errore da un server terzo che non e' il tuo
B) (opzionale) Banalmente qualcuno insiste a mandargli mail a un
indirizzo sbagliato
Per non parlare di quelli che omettono il dominio quando si devono
loggare da qualche parte.


 esista" <g>
In una situazione del genere io userei comunque il record per lo scoring:
una mail da 
pi...@tiscali.it
 che arriva da 213.205.33.1 la prendo
per score -1, una da 89.97.183.23 la prendo con score 0.
Sbaglio?
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 Sai che statisticamente i coglioni sono piu' dei non coglioni?
Non è solo un problema di coglioni/non coglioni.
Capita a volte che passi un tennico telecom (chissà perché sempre loro) per 
controllare l'adsl e gli riconfiguri il server di posta sui client "perché 
altrimenti non funziona"
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu

 Sbaglio?
Bah. ?all starebbe per van tutti bene. Quindi utilizzarlo è arbitrario 
nel senso che chi gestisce quel dominio non li esclude. Ma siccome sei 
tu l'arbitro sul tuo sever, come diceva Boskov " -1 è quando arbitro 
da!" :-D
Per andare oltre servirebbe sapere come sono strutturati, ma se non ci 
mette la mano sul fuoco nemmeno chi ha compilato l'SPF perchè dovresti 
fartene carico tu ? :)
Dal mio punto di vista è più un: "O nerdoni ... non filtateci perchè 
non abbiamo l'spf ... non scherziamo deh. Cielabbiamo !" magari ci 
fosse qualche fanatico che implementasse un domani una policy del 
genere. Qualcosa in stile dott. Paraloculo.

 Bah. ?all starebbe per van tutti bene.
Si ma visto che indicano i loro ip io ragiono con 'sono tutti uguali e
questi sono più uguali' :-)


 questi sono più uguali' :-)
No
"manco pè gnente" :) !!
Vedi il discorso in quel caso è semplice, qualcuno ha fatto loro
notare che, pubblicare un record SPF avrebbe "migliorato la
loro sender reputation" a quel punto, dopo essersi ammattiti
per capire da dove uscissero le mail legittime, visto che non
ne avevano la più pallida idea, hanno scoperto che esisteva
il "?all" ed hanno quindi deciso di pubblicare un record SPF
che non serve assolutamente a nulla ... MA ...
Se i legittimi proprietari del dominio (
tiscali.it
 in questo caso)
dichiarano "questi sono gli indirizzi IP dai quali, in teoria, ti
arriveranno emails, però, siccome non so neanche io se siano
corretti, tu fai finta che io non abbia detto nulla ed accetta le
email anche se arrivano da hosts diversi" non vedo per quale
motivo tu, in violazione di tale volontà ed allo stesso tempo in
violazione delle specifiche SPF debba rifiutare una email se
l'IP mittente non è uno di quelli elencati nel record SPF di un
dominio emittente che, come in questo caso, specifica un
"?all" che, appunto significa "fregatene del record SPF, tanto
un record fatto così non serve ad un tubo"

 l'IP mittente non è uno di quelli elencati nel record SPF di un
Forse non mi sono spiegato bene: la mia idea non è di rifiutare
alcunché, ma di dare scoring negativo in caso in cui il messaggio
arrivi da uno di quegli ip. Se (mettiamo) a 5 punti per me è spam
e un messaggio ha 5 punti, ma arriva da uno di quegli ip, per me
è un messaggio da 4 punti e quindi non è più spam.
Non so se mi sono capito...


 alcunché, ma di dare scoring negativo in caso in cui il messaggio
E per quale motivo ? Se seguissi le specifiche SPF potresti fare
quanto sopra nel caso di un "~all" ossia un "softfail" mentre nel
caso di un "?all" (neutral) in pratica è come se il record SPF non
esistesse, se poi vuoi fare come ti pare, libero di farlo, ma la
cosa è totalmente in contrasto con le specifiche; già che ci siamo
http://www.openspf.org/SPF_Record_Syntax
e, se dai un'occhiata al documento di cui sopra scoprirai che
nel caso di "?all" ossia "neutral" l'azione che ci si aspetta è
"accept";
la tua idea di fare scoring sarebbe corretta SE applicata a "?all"
in tal caso, un "softfail" dovrebbe incrementare lo spamscore del
messaggio in transito o comunque attivare dei controlli più "stretti"
sullo stesso

 sullo stesso
Ecco, io invece voglio diminuirlo o allentare i controlli.
Sbaglio? Ok, non lo faccio :-)
