Newsgroup: it.news.net-abuse
Titolo: Meccanismi SPF, dubbi (lungo)

Ciao a tutti,
stavo guardando con un certo interesse alla possibilità di 
plubblicare i record SPF per i miei domini 
x-privat.org
 ed
x-planet.org
.
Prendiamo come esempio il dominio: 
x-planet.org
se ho capito bene, inserendo un record TXT nel mio DNS come:
"v=spf1 +mx -all"
informo chi fa interrogazioni DNS sul questo record TXT che la 
posta autorizzata per 
x-planet.org
 è solo ed esclusivamente 
quella proveniente dai miei MX, ovvero
mail.x-privat.org
.
e
news.x-privat.org
 (il secondario, MX20)
giusto?
Viceversa se inserisco:
"v=spf1 +all"
dovrebbe significare che qualsiasi indirizzo ip è autorizzato ad 
inviare posta per il dominio 
x-planet.org
Ho notato ad esempio che pochi mi pare usino questo record, che 
apparentemente però potrebbe risolvere non pochi problemi legati 
al riconoscimento di 'posta lecita'.
Ho provato quindi con Libero.it, 
tin.it
, 
bofh.it
, 
spin.it
 per 
fare degli esempi concreti, ed in nessuno di questi compare un 
record TXT legato a SPF.
ho provato allora con 
abuse.net
 e mostra appunto:
"v=spf1 +all"
probabilmente proprio perchè il loro scopo è che nessuno filtri 
in base a SPF per il loro dominio, o sbaglio?
Supponiamo quindi che la mia scelta sia di applicare un record 
TXT per i miei domini, come:
"v=spf1 +mx -all"
Supponiamo quindi che il dominio xxxx.xx voglia interrogare il 
mio record TXT per verificare se la mail con 
MAIL FROM 
in...@x-planet.org
 provenga proprio da un mio server.
Quindi con il suo tool verifica se esiste un record TXT per 
x-planet.org
, lo trova e vede che gli IP validi per 
x-planet.org
 
sono appunto:
217.22.228.18 (
mail.x-privat.org
)
e
81.174.12.30 (
news.x-privat.org
)
in questo caso con la regola: "v=spf1 +mx -all" lascierebbe 
passare la mail come valida.
Supponiamo però che l'interrogazione SPF dia come responso un ip
qualsiasi che non siano i miei MX, in questo caso per la regola 
che ho messo la mail sarebbe rifiutata, giusto?
Se è così, mi chiedo allora il perchè questa tecnologia sia così 
poco usata, perchè non mi sembra affatto un cattivo metodo per 
isolare posta non lecita. Perchè?
Inserendo poi ua regola come:
"v=spf1 +mx ~all"
in pratica il risultato SPF sarebbe un SOFTFAIL, ovvero una 
condizione di non sicurezza, ma non assolutistica come -all .
A che pro?
-- 
Ciao, Dmitry
I've a dream... bring usenet to every family 

 metodo per isolare posta non lecita. Perchč?
mhmm ... forse ci sono. (mi rispondo da solo)
quindi con la regola: "v=spf1 +mx -all"
se l'utente 
in...@x-planet.org
 non utilizza un mio MX ma ad 
esempio l'SMTP del suo provider, la mail verrebbe rifiutata da
chi utilizza SPF come controllo sul mio record TXT di x-
planet.org
Cosě almeno sembra da:
http://www.dnsstuff.com/pages/spf.htm
In sostanza con questa regola, obbligo i miei utenti ad usare il 
mio SMTP se non vogliono incorrere nel pericolo che qualche 
altro sito usi SPF per verificare gli SMTPP di connessione. 
Vero?
per questo la usano in pochi? :)


 per questo la usano in pochi? :)
e quindi forse č il caso di inserire almeno un:
"v=spf1 +mx ~all"
giusto per lasciare il dubbio .. e dare il SOFTFAIL, ok?



SOFTFAIL significa che la mail non proviene da un server autorizzato ma non 
deve essere rigettata: deve solo essere sottoposta a ulteriori accurati 
controlli (data in pasto ad un filtro antispam, ad esempio).
Noi configuriamo per i nomi a dominio ~all, visto che ai clienti 
comunichiamo che possono usare indistintamente il nostro server smtp 
piuttosto che quello del loro provider di connessione. Dare -all creerebbe 
troppi casini, almeno per ora.
Se poi, un giorno, SPF verrà adottato da tutti, si spera, potrà avere senso 
sensibilizzare il cliente ad usare sempre in ogni caso solo i server smtp 
autorizzati nella sender policy del loro dominio.

 sender policy del loro dominio. 
basterebbe, almeno in Italia, che lo adottassero tutti i grossi 
e medi ISP ..



...e tutti i fornitori di caselle di posta gratuiti.
Basterebbe che, di comune accordo, altrimenti non serve a nulla, 
pubblicassero una tabella di marcia del tipo:
1) dalla data .... reject dei messaggi con stato SPF FAIL.
2) dalla data ...., in aggiunta a 1, reject anche dei messaggi con stato SPF 
SOFTFAIL.
3 dalla data ....., reject di tutti i messaggi ad esclusione di quelli con 
stato SPF PASS (il che implica rifiutare anche la posta da domini senza spf 
record configurato..
A questo punto tutti si adeguano, e si riduce il pishing e tanta posta 
generata da virus.
Solo che non si capisce nemmeno quale standarda prevarrà, c'è anche domain 
key ed altro, che si mettano d'accordo.

 key ed altro, che si mettano d'accordo.
Il "mettersi d'accordo" richiede della sperimentazione sul campo,
sperimentazione che e' in corso da tempo coi vari standard e con
la partecipazione di grossi ISP (ad esempio AOL, Yahoo, Earthlink).
"Mettersi d'accordo" anzitempo senza un riscontro sperimentale 
sarebbe un errore, l'email e' un sistema complesso e variazioni
architetturali non si possono mettere in piedi da un giorno 
all'altro.  L'enfasi sul path di trasmissione che caratterizza SPF, e che 
all'inizio ha attratto tutti su basi teoriche in quanto attuabile a 
livello di protocollo (quindi senza dover accettare la mail), ha
dimostrato sul campo di costituire un grosso handicap.
Il whitepaper di MAAWG dell'8 luglio
[ 
http://www.maawg.org/about/whitepapers/spf_sendID
 ] fa un po' il
punto della situazione come appariva l'estate scorsa. La situazione
e' in evoluzione, e un consenso generalizzato verso una soluzione non e' 
probabilmente da aspettarsi entro tempi brevi.
furio

 c'è anche domain key ed altro, che si mettano d'accordo.
agire sul dns mi sembra di per se una scelta semplice e veloce.


 ha scritto nel messaggio 
news:dnfhta$h8g$1...@half.spin.it...

Non posso che essere d'accordo con te.
Certamente non si puņ passare a spf o altri metodi da un giorno all'altro, 
soprattutto in realtą complesse come nei grandi ISP, ci vorrą il tempo che 
ci vuole.
Non posso comunque che chiedermi quanto del tempo trascorso sia stato (č) 
realmente destinato alla sperimentazione piuttosto che essere un 
temporeggiare dettato da ragioni di tipo commerciale.
Ottimo documento di sintesi, grazie, mi ci sono ritrovato.
Come nella necessitą di creare dei TXT record per spf associati al fqdn 
passato dai mail server nel comando HELO e i problemi con forwarder e 
mailing list utilizzando -all. I forwarder hanno sicuramente problemi 
con -all sui miei server, le mailing list invece sono ok, visto che 
l'exploder cambia il return path, utilizzato poi nel MAIL FROM:, 
nell'indirizzo del list owner al posto di quello del poster originario.

Se poi, un giorno, SPF verrà adottato da tutti, si spera, potrà avere senso 
Qui in generale non lo si spera, e per fortuna è altamente improbabile
che accada.
-- 
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

 improbabile che accada.
perchè pensi così? Quali controindicazioni trovi in SPF?


 plubblicare i record SPF per i miei domini 
x-privat.org
 ed
Domanda:
Allo stato attuale delle cose chi usa le info SPF per filtrare la mail
(al limite includendole in un qualche meccanismo di scoring?)
Non vorrei fare della facile polemica ma mi sa che ci si e` inluppati
nel meccanismo (non uso le info SPF perche` nessuno le pubblica / non
pubblico le info SPF perche` nessuno le legge.)

 nessuno le legge.) 
aggiungere un record TXT non costa nulla, non vedo 
controindicazioni francamente. Sul fatto di usarli, non saprei 
dirti al momento.
perņ a me č venuta anche una altra idea, creare dei record TXT 
per altri servizi, non escludo neppure un utilizzo in usenet, ci 
sto pensando ..
Alla fine, una interrogazione DNS č banale e i DNS hanno il 
grande pregio della propagazione universale e quindi mi sembra 
questa, cmq, la direzione corretta.



L'SMTP come è stato concepito poteva andare bene sulle reti accademiche dove 
si è sempre prediletto la semplicità d'uso e l'efficienza a discapito della 
sicurezza.
Bisognerebbe eliminare i pisher e gli spammer, a questo punto si potrebbe 
tornare fare pure a meno dei filtri antispam  che sono un'altra gran fonte 
di casino, perdita di tempo e soldi. Ma questo, si sa, è un'impresa 
impossibile.
Io sono per il prevenire piuttosto che curare quindi favorevole a questi 
meccanismi. E' sacrosanto diritto di ogni organizzazione che usa la posta su 
internet poter stabilire quali server sono autorizzati ad inviare posta 
leggittima originata da loro e prevenire abusi da parte di terzi.

 terzi. 
agree 100 %. direzione giusta, imho.


L'SMTP come è stato concepito poteva andare bene sulle reti accademiche dove 
Lungo discorso che non c'entra una cippa con i problemi di SPF.
Guarda DKIM piuttosto.



Perchè non c'entra nulla? Il problema è proprio l'SMTP che permette di 
passare HELO "quello che vuoi" e MAIL FROM: "quello che vuoi", SPF fornisce 
un metodo molto semplice, senza ricorrere alla crittografia e manipolare 
header e body, quindi più trasparente,  per verificare che il messaggio 
proviene da un MTA autorizzato a originare posta per un dato dominio.
DKIM o Domain Keys danno molti più problemi di SPF. Se non riescono ad 
implementare nemmeno SPF dubito molto che risciranno mai a introdurre DKIM.

 implementare nemmeno SPF dubito molto che risciranno mai a introdurre DKIM.
SPF da' molti piu' problemi di DKIM  (essenzialmente perche' "le vie
di trasporto mail usate dagli utenti sono infinite", e SPF e' legato
al trasporto mentre DKIM no).  DKIM da' molti meno problemi in userlandia
-- questo e' quanto dicono coloro che di utenti ne hanno a milionate.
furio

 controindicazioni francamente. 
Dipende da come e' fatto il record, comunque le controindicazioni
ci sono eccome e sono largamente state discusse e hanno a che fare
col path di trasmissione dei messaggi che spesso e', per motivi
legittimi, del tutto diverso da quello indicato nel record SPF.
furio

 ha scritto nel messaggio 
news:dnhigv$qp6$1...@half.spin.it...

SPF è path based, su questo non si discute con tutti i pregi e difetti che 
questo comporta.
Personalmente trovo più complicato "imporre" DKIM piuttosto che SPF.
Ti faccio subito un esempio:
Un cliente, che ha una linea dedicata/adsl con ip fisso o un netblock 
assegnato, mi chiede di poter operare con il suo server smtp interno per la 
posta in uscita in modo autonomo.
Implementazione di SPF per far funzionare la posta originata da lui:
- aggiunta sul DNS nella stringa spf del cliente di 
"IP4:xxx.xxx.xxx.xxx/xx". Il cliente è già in marcia per inviare mail.
Implementazione di DKIM:
- Chiamare il cliente per chiedergli che software usa come MTA
- Il cliente ha un software proprietario che non supporta plugin DKIM per 
firmare digitalmente la posta in uscita----------------->DEAD END
- Convinci il cliente a cambiare software (comunque è incazzato), gli 
installi DKIM.
- generi le chiavi pubbliche/private
- installi la chiave privata da lui
- pubblichi la chiave pubblica sul DNS.
Per non parlare dei problemi successivi di manutenzione, perdita della 
chiave privata, hackeraggio/furto: gli rubano la chiave privata e chiunque 
da qualunque posto puo mandare fuori posta per conto suo, ecc.
DKIM ti obbliga ad installare il supporto già solo per i server SMTP che 
generano posta in uscita od usare uno smart host (path based anche qua?) ad 
un server con DKIM installato.
In questo scenario. Quale dei due metodi è il migliore? Path based o message 
based?

 ci sono eccome e sono largamente state discusse e hanno a che fare
E` chiaro che non puo` assurgenre a "criterio assoluto" ma solo entrare
in meccanismi di scoring. Da questo punto di vista l'impementazione di
SPF puo` diventare molto onerosa dal lato di chi riceve la posta, piu`
che dal lato di spedisce ...

 Path based o message based?
indubbiamente SPF, imho ..


 Spin ed altri 
Non so se possa essere utile alla discussione, ma da alcuni giorni la 
posta in arrivo sul mio account @
iol.it
 presenta l'header Received-SPF:

 diverso da quello indicato nel record SPF. 
beh, ci sono indicazioni precise su come implementare un record 
TXT per usare SPF, non c'è nulla da inventarsi, basta leggere.
Molto imho.


 l'header Received-SPF: 
potrebbe signifiare che usa SPF, però strano che non vedo la 
pubblicazione dei suoi record, boh. Mi riporti l'header 
completo?


 
Un esempio:
Received-SPF: neutral (
smtp12.libero.it
: 155.158.58.144 is neither 
permitted nor denied by domain of 
ghanalounge.every1.net
) 
client-ip=155.158.58.144; envelope-from=
saus...@ghanalounge.every1.net
; 
helo=
pc144.ds4-s.us.edu.pl
;
Incidentalmente è tratto da un messaggio di spam.

 ha scritto nel messaggio 
news:u55u63-...@mybox.xp.it...

E' 
ghanalounge.every1.net
 a pubblicare una policy "neutral":
ghanalounge.every1.net
  text = "v=spf1 include:
sitespf.everyone.net
 ?all"
SPF e anche gli altri metodi servono per prevenire il phishing non lo spam. 
Anche gli spammer possono pubblicare una policy per il loro nome a dominio, 
SPF, Domain Keys o altro che sia.
E se questo non è il suo dominio.... io una policy "neutral" non la 
pubblicherei mai per un dominio.

 per te si chiama dig ed è perfetto per un castoro, eheh :-)
uso anche dig :) ma devi capire che dig sotto win non esiste ed 
io sul mio desktop ho sempre aperta la shell di unix e spesso 
faccio dei comodi copia ed incolla :)
per fare questo, devo usare per forza nslookup, che dig su win è 
un sogno :)


 Incidentalmente è tratto da un messaggio di spam.
ti ha già risposto gianni


 pubblicherei mai per un dominio.
No, certo, ho precisato che si trattava di spam solo per completezza di 
informazioni. Me ne sono arrivate anche di legittimi :)

 based?
Se parliamo di "complicazione", è indubbio che SPF sia più lineare.
E probabilmente, per lo stesso motivo, è destinato a rimanere lettera
morta o quasi.
Il problema è che il sistema SMTP attuale (e con esso l'uso che ne viene
fatto dagli utenti) *non è* "path sensitive", nè lo è mai stato... :-\
Non si riesce a convincere la gente che è una idea del ca##° usare un
SMTP che gira sul proprio portatile e che fa direct-to-mx, figuriamoci
mandare in testa all'utenza che le mail con mittente con 
X...@libero.it
va spedita con i server di Libero e che quelle con mittente
X...@tiscali.it
 vanno spedite con quelli di Tiscali...
Tanto, funziona lo stesso, e se la mail non passa è l'ISP del
destinatario che è cattivo :-\
Si arriva quindi alla situazione in cui usare il record SPF per il
blocco è impensabile, e usarlo per i meccanismi di scoring è inutile,
poichè incide in ugual maniera sia in positivo che in negativo.
Dove porta, 'sta strada? Probabilmente, da nessuna parte...
Una cosa come SPF sarebbe stata una gran pensata se fosse stata
implmentata quando l'utenza era ancora quell'embrione skillato.
Implementarlo ora è probabilmente infattibile (e l'esperienza dei grossi
ISP che ne hanno studiato l'applicabilità va in questa direzione).
Qualunque sia la soluzione atta a implementare un meccanismo di
validazione del mittente, non dovrà presumibilmente appoggiarsi sulla
consapevolezza dell'utente. SPF lo fa.

 destinatario che è cattivo :-\
Se lo fanno tutti, alla fine gli utenti si adattano. Francamente educare 
gli utenti dovrebbe essere uno degli obiettivi da raggiungere.
L'altro giorno parlavo con il figlio di un mio amico che, candidamente, 
mi ha detto di formattare il PC una volta ogni 2 o 3 mesi per liberarlo 
dai virus. Gli ho suggerito di installare avast e sygate (si trova 
ancora in giro), ma lui, sempre candidamente, ha ribattuto che 
riformattare (e reinstallare WindowsXP rigorosamente pre-service pack 2, 
perché quest'ultimo penalizza col software P2P) gli costa poco e che 
firewall e antivirus gli "levano un bel po' di fps" nei giochi online... 
Come fai a spiegare ad una persona del genere che ha responsabilità 
anche nei confronti dei terzi?
Tu stesso mi avevi parlato  dell'importanza di chiudere la porta 25 a 
livello di router di confine dei singoli provider. Il concetto non è 
forse il medesimo? Anzi, SPF sarebbe probabilmente meno traumatico.

 ha scritto nel messaggio 
news:dni0v0$ihf$1...@half.spin.it...

Il tuo discorso non fa una grinza, sfondi una porta aperta.
Tutto questo discorso è stato originato dicendo: c'è SPF, Domain Keys ed 
altro... si mettano d'accordo su cosa è meglio usare. Si scelga il minore 
dei mali e poi ci si adegua.
Il fatto è che anche DKIM, volente nolente è path based, almeno all'origine.
Pensi forse che spedendo un messaggio da Tiscali con email 
ute...@libero.it
, 
il server di Tiscali te lo firmi digitalmente con la chiave privata di 
libero.it
?
Siamo punto a capo, in ogni caso l'utente dovrà mandare il suo messaggio al 
server di "partenza" giusto.
E poi DKIM è questa grande novità? Firmare digitalmente il messaggio con un 
meccanismo di auto verifica lato MTA. Ok, solleva l'utente da qualche 
controllo ma, in definitiva, non si ottiene lo stesso installando sul 
proprio client un certificato digitale per la posta?
Io, anni fa, ho avuto dei problemi con qualcuno che mandava messaggi in giro 
usando il mio indirizzo personale. Cosa sono stato costretto a fare? Ho 
acquistato un certificato digitale da Verisign associato al mio email e 
firmavo digitalmente tutta la posta che spedivo. Nella signature avevo 
scritto: se la verifica fallisce o il messaggio da email non è firmato non è 
il mio! E fine dei problemi di phishing.

 sarebbe probabilmente meno traumatico. 
agree


 Mi fa piacere vedere che ti stai evolvendo, alla fine :-)
ovviamente ti riferivi al copia ed incolla immagino :))


 gli utenti dovrebbe essere uno degli obiettivi da raggiungere.
Sfondi una porta aperta, per citare chi mi cita... :-D
Il problema č che l'unico modo di forzare gli utenti a rispettare delle
regole č tramite il disservizio, e c'č un limite al livello di
disservizio che si puň "erogare". :-D
Quello che bisogna stabilire, quindi, č quale meccanismo tra quelli
ipotizzati fornisce i maggiori vantaggi, a fronte dei minori disagi.
Quello che pare emergere da questa prima fase di sperimentazione č che
SPF fornisce pochi vantaggi rispetto agli svantaggi che si porta dietro.
Puň essere che gli altri prospettino rapporti costi/benefici anche meno
vantaggiosi, e che quindi SPF torni fuori e prenda il sopravvento. Per
il momento, perň, non č cosě... :-\

 il mio! E fine dei problemi di phishing.
E chi riceveva solo le mail "dell'altro", e quindi non leggeva la tua
signature? ;-)

 signature? ;-)
Eh... già. DKIM, da questo punto divista, qualche servizio in più lo offre! 
:-)

 leggittima originata da loro e prevenire abusi da parte di terzi.
Però vi sono dei problemi pratici e ti faccio un esempio di qualche
giorno fa: un albergo ha una pagina con un form, gestito dal mio server
di posta; l'account locale che riceve la prenotazione lo inoltra
automaticamente verso un'altra casella su un dominio che non gestisco
io. Tale dominio è su un ISP che ha adottato SPF. Risultato: la posta
non viene accettata, ma lo vedo solo io sui log di errore del server.
Quindi con l'altro ISP mi sono dovuto mettere d'accordo e lui ha escluso
il controllo se la posta arriva dal mio IP.
Capirai che è una po' una menata, considerando che di posta inoltrata ne
gira parecchia. Non so come facciano quei grossi siti tipo 
venere.com
che gestiscono prenotazioni di ogni genere conto terzi.
Sicuramente vi sono altri problema analoghi nell'uso di SPF. Non so
quanto valga la pena adottarlo.
Gabriele Polidori

 forse il medesimo? Anzi, SPF sarebbe probabilmente meno traumatico.
Meno traumatico? Se una persona vuol installarsi il suo server di posta,
vuol dire che è un pelino più su dell'utonto medio e quindi dovrebbe
sapere che se poi non gli funziona (causa blacklist o blocchi della
porta) non si deve lamentare.
Gabriele

 il mio! E fine dei problemi di phishing.
A tal proposito infatti io non capisco perché quel sistema è cosi poco
usato; anch'io anni fa avevo preso per provare un certificato ad uso personale.
In tanti anni, mi sono capitate solo due altre caselle protette con quel
metodo (una di un abuse desk, mi pare di 
i.net
).
Boh, a volte si preferiscono le cose difficili, si vede che anche in
internet c'è qualcuno all'Ufficio Complicazioni Affari Semplici ;)
Gabriele

 il controllo se la posta arriva dal mio IP.
Se il form è generato da php, usi sendmail in pipe con il parametro -f che
forza il FROM nell'envelope al valore che specifichi.
Spf lavora con l'envelope e quindi risolvi il problema.
Altrimenti sempre in php lo fai lavorare in direct-to-mx forzandogli i
parametri e risolvi il problema (se ho capito come girano le cose)
Max

 porta) non si deve lamentare.
Illuso... :-P

 usato;
La risposta è nel termine "acquistato" = soldi da sborsare che mal si
concilia con la filosofia del tutto, subito e gratis.
Sarebbe la soluzione definitiva (una spesa irrisoria per un uso
legittimo della posta ma un costo insostenibile per uno spammer) ma
anche qui ci si scontra con la necessità di imporre una accettazione
generalizzata.

 A che pro?
Invece di imbarcarmi in una discussione sui perchè
o percome del meccanismo SPF, ti consiglio di dare
una bella occhiata qui 
http://www.openspf.org/
 - credo
che troverai tutta la documentazione ed i chiarimenti
che ti servono; detto questo, se quello che ti serve è
abilitare SOLO gli MX ad inviare email per i domini in
questione, ti basterà un record SPF di questo tipo
"v=spf1 mx ~all"
ossia che abiliti SOLO gli hosts definiti come MX nel
DNS all'invio della email; ovviamente, se avessi la
necessità di aggiungere altri hosts, potresti estendere
quanto sopra inserendo es. "a:" o "ip4:" ecc...
Ciao
-- 
* ObiWan
Microsoft MVP: Windows Server - Networking
http://www.microsoft.com/communities/MVP/MVP.mspx
http://italy.mvps.org

 
x-planet.org
.
<snip>
Dimenticavo
http://snipurl.com/kpav
Ciao


From: <utentech...@suodominio.tld>
Subject: Prenotazione camera
questo funziona.
Prova a fare la stessa cosa con DKIM. L'invio di una mail del genere č 
semplicemente irrealizzabile. Non potrai fare piů di queste cose, cioč 
mandare mail, seppur leggittima, per conto di un altro utente.

 
Per risolvere i problemi con i forwarder puoi utilizzare srs
(
http://www.openspf.org/srs.html
)
 Ciriciao
  Gio'
-- 
/*
 * Solutions for New Business - 
http://www.snb.it
 */

 porta) non si deve lamentare.
Uhm, che motivo avrebbe qualcuno a metter su un server SMTP con un 
abbonamento che non prevede ip statico, se si esclude il caso di relay 
sul smtp del proprio ISP?

 quanto sopra inserendo es. "a:" o "ip4:" ecc...
non avevo un problema tecnico :) ma etico sull'uso o meno di 
SPF. Io ho già pubblicato i miei record:
[root@redpower root]# dig txt 
x-planet.org
; <<>> DiG 9.2.3 <<>> txt 
x-planet.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17575
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, 
ADDITIONAL: 5
;; QUESTION SECTION:
;
x-planet.org
.                  IN      TXT
;; ANSWER SECTION:
x-planet.org
.           1800    IN      TXT     "v=spf1 +all"
che era per fare delle prove. Sarà poi, quando avrò finito:
"v=spf1 ~all"
per dare solo un SOFTFAIl nel caso non siano i miei SMTP ad 
inviare ..


 sul smtp del proprio ISP?
Scherzi? Avere per MX un record su DynDNS *è fighissimo*!
E i server degli ISP son tutti amministrati di me*#@...

 sul smtp del proprio ISP?
I serveradmin *Wannabe* sono piů di quanto potessi immaginare.
Per far capire ad un cretino che porca trottola se mi mandava email da un
IP dinamico di alice non potevo accettare la sua posta, ci ho messo, e non
scherzo, 2 settimane.
Max

 alla gente.
Credo il problema stia a monte.
C'è stato un periodo, qualche anno fa, in cui internet doveva essere
gratis per tutti.
Far capire, ora, che si ha quel che si paga, è difficile...

 SMTP ad inviare ..
E che credo sia la forma più corretta.. oltre a questo
volendo potresti aggiungere un TXT per ciascun MX
definendo in tali records una policy più "stringente"
esempio:
x-privat.org
. IN TXT "v=spf1 mx ~all
mail.x-privat.org
. IN TXT "v=spf1 a -all"
news.x-privat.org
. IN TXT "v=spf1 a -all"
Ciao

 così facile farlo capire alla gente.
di utilizzare un SMTP libero che usa SMTP-AUTH no eh? :)


 doveva essere gratis per tutti.
non mi ero accorto che siamo in una nuova era ..


 
news.x-privat.org
. IN TXT "v=spf1 a -all"
si, anche. 


 E i server degli ISP son tutti amministrati di me*#@...
Be', per fini  didattici o di auto-apprendimento non ci vedo nulla di 
male, a condizione che non si abbia la pretesa che funzioni come un 
servizio di posta vero.
FW prevede la possibilità di inoltro della posta in arrivo ad un 
indirizzo anche sotto forma di nome@[ip address] e gli ip interni di FW 
sono in pratica fissi. Tutta la mia posta in arrivo viene inoltrata in 
questo modo ad uno dei miei PC con postfix, spamassassin, clamav e 
amavis e devo dire che ancora non è passato neppure un messaggio di spam 
o con virus. Postfix, ovviamente, non è openrelay ed ogni accesso è 
comunque monitorato (in ogni caso da firewall si può solo collegare a 
determinati server smtp).
La posta in uscita passa sempre attraverso gli stessi programmi 
(spamassassin escluso) e viene poi forwardata al server 
smtp.fastwebnet.it
 che si occupa di farlo pervenire alla destinazione 
finale.
Io spero che questo non mi assimili  alla categoria da te descritta. In 
realtà quello che mi premeva era bloccare lo spam e i virus in arrivo da 
una parte (l'armamentario sopra descritto fa meglio di quanto riescano a 
fare i filtri del mio provider) ed evitare che i miei PC domestici 
possano essere usati per mandare spam o spediscano porcherie via mail 
(uno dei PC è una macchina Windows). Ammetto anche di essermi divertito 
a metterlo su, ma non ho certo la presunzione di poter fare a meno di un 
ISP.
Se un giorno FW eliminasse la possibilità di forward con le modalità 
sopra descritte... pazienza, ne farò a meno.
p.s. ho fatto metter su submission sul server smtp dell'isp lavorativo, 
come da vostro suggerimento :)

 non mi ero accorto che siamo in una nuova era ..
Per esserci, ci siamo. Solo che ancora non tutti se ne sono accorti...
:-\

 come da vostro suggerimento :)
Dell'ISP direttamente? Pensavo fosse il server aziendale.
In ogni caso, di solito si tratta di decommentare una riga... ;-)

 Dell'ISP direttamente? Pensavo fosse il server aziendale.
No, abbiamo un serverino Linux (che ricalca più o meno quanto faccio a 
livello domestico, anche se solo per la posta in uscita, proprio perché 
voglio un sistema centralizzato e controllato di sicurezza a cui le 
segretarie non possano accedere... ho avuto brutte esperienze, una di 
loro eseguì un file chiamato "supertettone.exe", ricevuto per e-mail), 
ma poi fa relay sul server SMTP di chi ci cura la posta elettronica che 
è un esterno. In altre parole ogni workstation ha il suo antivirus 
(Norton o Mcafee), ma la posta in uscita passa comunque attraverso 
amavis e clamav.
 > In ogni caso, di solito si tratta di decommentare una riga... ;-)
Su Postfix è così, ma loro credo che usino Windows come piattaforma di 
elezione.
A proposito: chi mantiene il nostro server di posta elettronica ci ha 
avvertiti che Outlook Express non supporta submission con TLS...  a noi 
la cosa non tange, ma in effetti se si considera che OE è uno dei client 
più diffusi, si tratta di una bella limitazione :/

 o con virus. 
beh dai, ora non esagerare. Finche mi dici che non ti è passato 
manco un virus, posso crederti, ma neanche un messaggio di spam, 
francamente mi sembra davvero difficile ..
Io ho caselle 'comprate' anche con TIN, LIBERO ed altri, e 
qualcosina, poco, ma passa. Ovviamente anche con X-Privat.


 accorti... :-\
ad esempio, io no :)


 amavis e clamav.
era tettona.exe, è passato anche qui (ma non dalla segretaria ovviamente...)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
- Lei scopa?
- Ci ho provato, come tutti, nel '68.  Ma poi ne sono uscito.
		-- Altan

 ovviamente...)
Grazie per la precisazione :)

 
L'indirizzo e-mail è quello che vedi in chiaro qui: 
loren...@fastwebnet.it
. Non ce l'ho da molto, ad oggi ha ricevuto una 
cinquantina di mail indesiderate fra spam e virus, tutte messe in 
quarantena da amavis/clamav/spamassassin. Per ora posso dire di essere 
stato fortunato.

 dimostrato sul campo di costituire un grosso handicap.
Io ho visto un grosso relax da parte di grossi isp, alcuni esclusi, che se
ne sono ampiamente sbattuti anche dei tests.
Il problema è che ora la posta su internet è una grandissima anarchia.
Metodi come spf o dkim prevedono una partecipazione di specifici server
smtp che firmino o verifichino un messaggio.
Questa partecipazione di specifici server sottintende che gli utenti li
utilizzino e soprattutto lo capiscano.
Non credo che nessun provider grosso, che lavora di più sul blocco degli
abusi dopo segnalazioni (e nel caso di alcuni, nemmeno questo) se la senta
di insegnare, far migrare e poi forzare gli utenti a applicare certe
metodologie.
Allo stato attuale, per far funzionare spf o dkim, bisognerebbe che NON i
fornitori di connettività (mi collego con Infostrada, uso gli sMTP di
infostrada; ho una linea NGI, uso i loro smtp), ma i mantainer o comunque
chi gestisce i domini, forniscano un servizio di submission dietro
presentazione di credenziali di autenticazione e aggiornino i DNS.
(ovviamente non sarebbe "aggratisse").
Ora, supponendo che alcuni ISP lo facciano, ma altri non lo facciano,
implica che il sistema non funzionerà mai efficacemente. Anche l'utilizzo
del softfail in spf, ad esempio, previsto proprio per ovviare a queste
problematiche, è una grande cosa per i tests, ma inutile quando e se il
sistema prenderà piede. Ma fino a quando molti grossi isp non bloccheranno
i messaggi non firmati o più in generale, riconosciuti come validi, nulla
si sbloccherà, imho.
Potrà mai un server smtp scartare messaggi non conformi a spf? potrà mai
scartare messaggi non firmati con dkim ? Non credo proprio che potrà
accadere. 
Il problema è il raggiungimento di una certa massa critica che obblighi chi
non lo fa ad adattarsi. La massa critica imho si può raggiungere
esclusivamente a scapito degli utenti e generando disservizi. Quindi,
sempre secondo me, questi sistemi applicati alla attuale struttura sono
utopistici. Vedo la difficoltà simile alla migrazione a ipv6...
Max
P.S.: non vedo differenze tra spf e dkim sul piano della diffusione di
massa: le problematiche sono le stesse.

 diffusione di massa: le problematiche sono le stesse.
bisognerebbe avere qualche dato in proposito. nessuno ha 
verificato quanti e chi usa, ad esempio SPF ? Se però lo usa 
HotMail che certo non è un piccolo ISP, credo che qualche 
opportunità vi sia ..


 stato fortunato.
ma ricorda che la fortuna è cieca, e la sfiga ci vede bene :)


 comunque il problema resta farlo capire alla gente.
si, vero. Non ce ne sono tanti, e per ovvie ragioni direi. Però 
ci sono. Io trovo che cmq SMTP-AUTH dovrebbe essere adottato da 
tutti gli ISP..


 
già... E come fanno gli "omini telecom" che configurano le adsl poi a 
fare casino?
Gli togli il divertimento
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Dio non fa errori.  E' per questo che e' diventato Dio.
		-- Archie Bunker

 opportunità vi sia ..
Hotmail : softfail.
Zero funzionalità
Max


In quella maniera, molti ISP ti vogliono obbligare ad usare la loro rete per 
connetterti, soprattutto gli isp a servizio gratuito. A questo vanno 
aggiunte ragioni storiche, legate ad SMTP, per cui a questo servizio si è 
sempre permesso il relaying solo dalla rete interna del provider e negato al 
resto del mondo, aggiungici anche che i vecchi client di posta non 
prevedevano l'autenticazione sul server smtp per la posta in uscita...
Il servizio di posta, senza smtp per la posta in uscita, è un servizio 
zoppo. Quante volte ho visto gente collegarsi via Wi-Fi e non riuscire a 
mandare posta dalla loro casella proprio per i succitati motivi. Molta di 
questa gente non riesce neppure a trovare una spiegazione al "diffetto" 
quando gli capita e si arrende.. usa la webmail.... o non manda la mail. 
Purtroppo è alquanto forviante, alla luce dei discorsi fatti in questo 3d, 
insegnare ad un utente che per fare uscire la sua posta deve configurare 
tutte le volte l'smtp a quello del provider a cui si è connesso, perchè 
spacca spf, dkim et all.
Oggigiorno tutti questi problemi possono essere risolti, i provider di 
hosting, volente nolente, si sono già posti questi problemi risolvendoli con 
schemi di autenticazione che vanno dal semplice ma efficace "pop auth before 
smtp" fino ad arrivare a smtp auth basato su sasl.
Non c'è quindi da meravigliarsi che imporre sistemi quali spf piuttosto che 
dkim non possono che causare delle grosse grane, sia ai provider che agli 
utenti finali, e quindi riluttanza ad applicarli.

 Max
Può essere usato nell'ambito di uno scoring system. Per esempio: Zero 
punti per pass, xx per softfail e reject per fail.

 punti per pass, xx per softfail e reject per fail.
Teoricamente si.
Praticamente per me non ha senso.
Personamente come pratica, marco lo spam nel subject.
Il mio interesse non è marcarlo "ancora di più", poichè il "marcamento"
funziona bene...
Il mio scopo è bloccarlo, rifiutarlo proprio.
SPF (e dkim) nascono con lo scopo di riconoscere le mail non lecite con
precisione. Se ci lasciamo dietro dei "forse non è lecita" il sistema non
regge.
A prescindere che hotmail è proprio il dominio che attualmente mi sta dando
più fastidi, l'utilità è proprio quella di bloccare la mail, non farla
passare per aumentare lo scoring (imho eh)
Max

 passare per aumentare lo scoring (imho eh)
Ci sono tante opzioni, per il fail potresti usare un reject secco e per 
il softfail un greylisting.

 connetterti, soprattutto gli isp a servizio gratuito.
Il discorso (valido più per i "vecchi" accessi dial-up che per ADSL)
è che in questo modo l'ISP ha già tutto in casa il necessario per
mettere in relazione una mail di spam non tanto con un account (lo
spammer ne può avere decine) ma con un numero di telefono.
A proposito di "roaming users" ... c'è qualche esperto di DNS che mi
può dire come (bind9) si possa creare un CNAME per un indirizzo che
NON appartiene alla propria zona?
Vorrei fare in modo che quando il portatile di un utente tenta di
risolvere un nome tipo 
smtp.libero.it
, 
relay.fastwebnet.it
 etc. (se ci
si limita agli ISP italiani non sono molti) venga passato l'IP del smtp
corretto per quella rete ...

 Zero funzionalità
mica vero, è già un segnale. Del resto mettere -all è 
oggettivamente troppo rischioso.


 il sistema non regge.
non sono d'accordo. Il primo segnale può essere una condizione 
AND ad altre proprie.


 secco e per il softfail un greylisting.
con il graylisting si ha un ritardo per le e-mail e non è 
bello..


 Gli togli il divertimento
vero :)


 fino ad arrivare a smtp auth basato su sasl. 
possono, eccome. Si tratta do volerle le cose. Io, da sempre 
obbligo ad usare SMTP-AUTH, pur avendo la possibilità di 
autenticare su rete Eutelia, con ip assegnati per Freenet e 
verifica del caller-id. Si tratta di volerle le cose.


 con un numero di telefono. 
quando questi ha più account mail, semplicemente si disabilita 
sul radius l'accesso, tramite caller-id. Punto.


 problemi. 
se non erro (devo ancora provare), puoi anche fare traffic 
shaping vero? Ho in mente una cosina da fare giusto questa sera


 bello..
Non dico con tutte, solo con quelle la cui verifica spf dà softfail. Le 
mail buone passano subito.
Una verifica spf che dà come esito softfail è potenzialmente spazzatura 
ed il delay ha come scopo solo quello di concedere il beneficio del 
dubbio: al secondo o terzo tentativo la fai passare, ma probabilmente se 
è stato usato un programma di mass-mailing per spam, questo si ferma al 
primo tentativo... almeno si spera :)

 softfail. Le mail buone passano subito.
beh, così è decisamente più ragionevole :)


 a tuo agio con tcng 
http://tcng.sourceforge.net/
guardo anche questo, grazie :) C'è da dire che linux ha cmq una 
flessibilità semplicemente impensabile rispetto a win, c'è poco 
da dire ..


un sogno :)
Allora sogna pure 
http://snipurl.com/kr4v
aprilo piano e guarda che c'è dentro.

 Carletto, prova la via del pescione, non te ne pentirai :-)
??


 terribilmente OT :-) 
ho capito solo ora la battuta di Pier :) E' che lui ormai mi sa 
che si è fissato con OpenBsd :) Cmq, andiamo con calma, che già 
sono con fedora2 che già mi sta facendo incazzare :)


 aprilo piano e guarda che c'è dentro.
si, ma mi dovresti dare dei buoni motivi per usare dei software 
nativi linux su win, avendo a disposizione linux :)
non ne vedo di buoni motivi, francamente. Anzi, sotto linux mi 
sembra davvero tutto più semplice a dire il vero.
