Newsgroup: it.news.net-abuse
Titolo: SPF - stanno chiudendo

>> RSET
<<< 421 
smtp9.libero.it
 Error: too many errors

 "SPF fail. Please see at 
lol :)
-- 
Ciao, Dmitry
I've a dream... bring usenet to every family 

SRS.
Esattamente per questo motivo avevo suggerito di applicare SPF solo ai
domini per cui è effettivamente utile (cioè quelli oggetto di phishing),
visto che come hai appena dimostrato anche gli utenti più avanzati che
cercano di usare SPF non sono in grado di farlo del tutto correttamente.
-- 
ciao, |
Marco |  The Italian Usenet Cabal, Abuse Department (TINC)
"It's about damn time that all of us who actually give a damn about Usenet
stand up and tell the people who don't to fuck off and die." -- Russ Allbery


Qui, gli utenti avanzati, SPF lo stanno usando correttamente.
Sono semmai i provider che forniscono servizio di forwarding che non stanno 
ancora adottando meccanismi come SRS per supportare i sender che adottano 
SPF per proteggersi, scoraggiando appunto chi SPF lo userebbe proficuamente 
per difendersi dal phishing.
Il nocciolo della questione è proprio qua, volente nolente devi forzare 
tutti gli ISP ad adeguarsi, altrimenti nessun utente finale vorrà mai -all 
nella stringa SPF del proprio nome a dominio, se da un lato gli crea casini 
quando non dovrebbe e dall'altro è comuqnue soggetto a phishing perchè pochi 
provider fanno il reject su test con esito SPF Fail.


Guarda, facciamola molto piu semplice, altrimenti non se ne viene a capo.
Nel caso che ho riportato in questo 3d. Di chi č la colpa?
a) Del Sender che cerca di proteggere i sui interessi utilizzando SPF, e 
facendo uscire la posta da un suo MTA autorizzato?
b) Dell'ISP che gestisce il dominio .COM a cui il Sender ha inviato la mail? 
ISP che non riscrive il return path sui forward pertanto č la causa 
scatenante del reject.
c) Di Libero, che ha fatto il suo lavoro, rigettando un messaggio perche SPF 
ritorna Fail?

facendo uscire la posta da un suo MTA autorizzato?
Del mittente che invia posta a un sistema che fa forwarding senza
riscrittura. Certo nessuno deve sentirsi obbligato a implementarla...



Complimenti, 10 e lode.

 Complimenti, 10 e lode.
immagino sia ironico



eh, molto...
senza poi considerare il fatto che, su un servizio di forwarding, a 
prescindere dalle problematiche di SPF, il return path *andrebbe* riscritto 
comunque. Esattamente come andrebbe sempre riscritto dagli exploder di un 
servizio di mailing list.
Questo perchè se un messaggio forwardato genera un bounce in consegna sul 
recipient finale, questo bounce dovrebbe percorrere a ritroso la stessa 
strada del messaggio che lo ha generato.
Tutto questo va a favore della tracciabilità in caso di problemi prettamente 
tecnici.
In molti anni di posta, una buona fetta di problemi sulla posta li ho visti 
accadere proprio a causa di un uso selvaggio di caselle forwarder che 
provocavano, nel peggiore dei casi, mail loop infiniti, difficili da 
identificare velocemente.
SRS da questo punto di vista è positivo, poichè fa si che i bounce 
ripercorrano la stessa strada a ritroso, oltre a non spaccare il meccanismo 
spf.

 eh, molto...
appunto ..


 può essere una soluzione contro lo spamming.
Ehm .. Marco, SPF non è, e credo non sia mai stato inteso
come soluzione contro lo spamming, lo scopo di SPF è solo
quello di evitare il forging degli indirizzi, che poi questo aiuti
anche a ridurre lo spam beh.. tanto di guadagnato, tra l'altro
visto che implementare SPF non "costa" poi molto e visto che
tale meccanismo aiuta contro lo spam ed evidenzia parecchie
magagne di configurazione.. non vedo perchè non usarlo; del
resto è comunque un passo nella giusta direzione
Ciao

 nella giusta direzione 
quoto


magagne di configurazione.. non vedo perchè non usarlo; del
Direi che i problemi che ha mostrato chi ha iniziato questo thread sono
un buon esempio del perché non è una buona idea usarlo.



Il problema dei forwarder, in realtà, va ben oltre la questione SPF.
La maggior parte degli ISP che offre caselle forwarder, lo fa in mala 
maniera, utilizzando file .forward (ugh!),
tabelle aliases, virtusertable, ecc, che se anche fanno il lavoro, lo fanno 
comunque male.
Un servizio forwarder decente dovrebbe cambiare il return path, al più, pure 
aggiungere un header Sender:, ma questo non lo fa nessuno.
Quindi, facciamoci male, le cose funzionano, lasciamole funzionare così come 
sono, ma che tutto questo sia allo stato dell'arte è mera illusione e pura 
comodità.

aggiungere un header Sender:, ma questo non lo fa nessuno.
C'è abbondanza di argomentazioni per entrambi i metodi, quindi non mi
sembra che sia un problema così semplice come lo mostri tu.


 sono un buon esempio del perché non è una buona idea usarlo.
Nel caso in oggetto, il problema è causato da una errata configurazione
del record SPF del dominio mittente (
comi.it
), ossia, il server di "
comi.it
"
utilizza uno smarthost per la posta in uscita, ma, tale smarthost non è
stato inserito nelle informazioni SPF e questo causa il problema.. che
però è di facile soluzione (le istruzioni al proposito sono anche al link
indicato nel messaggio reject); se SPF evidenzia "magagne" nella
configurazione ... beh .. tanto meglio .. no ?

, giustamente 
204.200.222.210 non č autorizzato a mandare posta per 
comi.it
 quindi libero 
l'ha rigettata.

 sembra che sia un problema così semplice come lo mostri tu.
Scusa, ma sei un amministratore di sistema? Fare una cosa del genere è una 
cazzata da 2 ore di lavoro.

 l'ha rigettata.
Scusate se mi introduco nella discussione. Qualche giorno fa mi č 
arrivata una mail di spam con envelope uguale a <>, che, correggetemi se 
sbaglio, formalmente č assolutamente legale. L'SPF1 che si sta 
cominciando ad usare č quello vecchio stile (verifica solo envelope 
from) o quello classico che prevede controlli anche su HELO/EHLO?

 prevede controlli anche su HELO/EHLO?
Quello che si sta spingendo ad usare è SPF Classic. Quando viene passata una 
envelope nulla il controllo deve essere fatto sull'argomento passato a 
HELO/EHLO.

 del genere è una cazzata da 2 ore di lavoro.
direi molto meno, oibò.
