Newsgroup: it.comp.software.newsreader
Titolo: circa l'uso dell'ID utente

Premesso che :
1) l'idea di dare un ID a chi ne avesse bisogno da impostare nel 
proprio newsreader mi è venuta per far contenti una certa cerchia
di utenti che già lo fanno con Individual (non lo ritenevo così 
importante ma va bene)
2) ritengo in topic questo eventuale thread in quanto si parla cmq
di impostazioni di un newsreader
3)è per me importante il parere dei miei utenti e di eventuali a 
venire (ed anche di utenti non miei ovviamente)
Vi sono secondo me diverse possibilità:
1) Assegno ad un mio utente che ne fa richiesta la stringa (non 
prendetela per buona, ancora non ho deciso come sarà)
XPFS-02939.x-privat.org
e questa stringa viene messa nella parte destra dopo il @
2) come sopra ma la stringa viene messa prima del @
Nel primo caso si può parlare di FQDN ed un nslookup confermerà 
quanto detto. Nel secondo caso non è altresì corretto inserire una
stringa di questo tipo nella parte sinistra, quantomeno usuale ed
il risultato sarebbe, ad esempio:
[serie di numeri generati]
XPFS-02939....@x-privat.org
Credo che tutti siamo d'accordo sul fatto che cmq, anche se alcuni
newsreader non lo permettono, detta stringa andrebbe impostata
dopo il @.
A questo punto bisogna decidere cosa fare nel caso in cui un ID 
utente assegnato ad un mio utente viene utilizzato non
correttamente. 
Quindi vi sono tre ipotesi di spoofing:
1) un mio utente "usurpa" la stringa e la usa per i suoi
cavolacci. 
2) un utente non mio ma di altro ISP prende la stringa :
@
XPFS-02939.x-privat.org
e la usa per se.
3) un utente non mio ma di altro ISP prende la stringa:
@XPFS-02939 (quindi senza il dominio)
e la usa a modo suo .
FINE PREMESSA.
ora ... Io la vedo così, correggetemi se sbaglio:
Nel primo caso si tratta di un mio utente e quindi la cosa più
logica è scrivere al MIO abuse che provvederà di conseguenza
verificando a quale utente è realmente appartenente detta stringa
ID. Se è un abuso effettivo l'utente sarà avvisato di non
ripeterlo e se non rispetta e/o corregge un suo errore, si vedrà
l'account eliminato. 
Nel secondo caso semplicemente imposto una regola a livello di 
cleanfeed che, per i post non locali e quindi che non provengono
dai miei server, una tale stringa viene semplicemente rigettata e
quindi il relativo post eliminato dai server.
Nel terzo caso non faccio proprio nulla per il semplice fatto che
una stringa come: @XPFS-02939 non posso dichiararla mia in quanto
non è parte dei miei domini e si tratta solo dii una serie di
numeri. 
Cosa ne pensate?
-- 
Ciao, Dmitry

Premesso che :





XPFS-02939.x-privat.org






Quindi vi sono due ipotesi di spoofing:


| going to translate them any time soon ... :)] 
pensa :) 
-- 
Ciao, Dmitry

 usarlo "legalmente").
Mi piace :)
-- 
Enrico C
"Fabbricare fabbricare fabbricare
Preferisco il rumore del mare"

 server, ho capito bene ?
assolutamente uno lo usa solo se vuole, ci mancherebbe :)
-- 
Ciao, Dmitry

 usarlo "legalmente").
E così con queste ultime parole hai anche risposto alla mia domanda
iniziale, da cui è scaturito tutto questo pandemonio, sul fatto che se
non rinnovo l'abbonamento al server tedesco dovrei trovarmi un altra
nuova stringa, ché quella vecchia mi decade il diritto di usarla ;-(
A riguardo delle frasette di spiegazione, giusto stamattina (ore 9) mi è


 @XPFS-02939 (quindi senza il dominio) e la usa a modo suo .
il caso 3 è fuori discussione, non ci fai niente
il caso 2 è un netto abuso se l'autore non è un tuo utente, ma diventa 
legittimo se è un tuo abbonato che però posta anche da un altro ISP 
(tipo quando il tuo NS è stato down): sempre che nel rilascio del fqdn 
non metti come clausola che si può utilizzare solo per invii tramite 
x-privat.
il caso 1: intendi che un tuo utente utilizza la stringa di un altro 
tuo utente o un caso come la seconda parte del punto 2 qui sopra?
-- 
Sàns

 quello assegnato dal server, ho capito bene ?
hai capito bene infatti :)
-- 
http://snipurl.com/aq1q
~ We've got stars directing our fate ~

 
si, anche. Pensavo però al fatto dei filtri automatici. se uno abusa 
usando un open proxy e un tunnel con qualche servizio free, hai 
voglia a contattare l'abuse di quel servizio ..
Forse sul filtro automatico c'è da pensarci bene.
-- 
Ciao, Dmitry

 lettori, come hanno ben detto altri.
se ben impostato è impossibile che danneggi un utente x-privat. Mi 
spiego, vi è una netta differenza a livello centrale tra quello che 
arriva da feed e quello che è invece un post locale. Questa semplice 
divisione impedisce di fatto un errore nel filtro
-- 
Ciao, Dmitry

proprio newsreader mi è venuta per far contenti una certa cerchia
comunque se un utente usa il suo FQDN i suoi msg vengono accettati, giusto ?
non è che è obbligatorio per tutti usare quello assegnato dal server, ho
capito bene ?
-- 
PaoloR     [ 
www.ruata.net
 ]

 x-privat.
sarebbe molto scomodo per chi usa più di un server, però...


 Forse sul filtro automatico c'è da pensarci bene.
Beh, una ipotesi transitoria potrebbe essere di pensare ai filtri in un
secondo tempo, solo in caso ti venissero segnalati un certo numero di
abusi... cmq vedi tu, ovviamente :)


 un certo numero di abusi... cmq vedi tu, ovviamente :)
anche questo è vero. Infatti stiamo discutendo su delle ipotesi. 
Peraltro prima che attuo il tutto mi ci vorrà un pò perchè sono 
indeciso su quale id dare all'utente, ovvero:
1) per anzianità di registrazione
2) generazione MD5
3) generazione random sulla data di registazione
4) stringa crittata con altro algoritmo.
Insomma, devo pensarci bene, perchè poi non potrò cambiarla ..
-- 
Ciao, Dmitry

 sopra? 
intendo la prima ipotesi, ovvero che ad un mio utente stia antipatico 
un altro mio utente e vuole giocargli il colpo gobbo, peraltro 
sarebbe uno scherzo da prete, scusate gli eufenismi :)) ma si sa che 
sono un tipo strano :)
A parte gli scherzi. il caso 1, come il 2 sono alquanto improbabili, 
ma se anche succedesse il rimedio da me proposto mi pare accettabile. 
che ne dici?
-- 
Ciao, Dmitry

 numeri.
Se tu usi [stringa casuale]@
XPFS-02939.x-privat.org
 il dominio è il tuo.
Se qualcuno vuole usare @XPFS-02939.altro ovviamente va bene, ma non vedo
il problema. Chi vuole tracciare i suoi post tramite i M-ID e References lo
può fare senza dubbi di falsi positivi.
In compenso se qualcuno prova a realizzare un fake ben fatto prendendosi
tutto il dominio commette un abuso. Mettere l'ID a sinistra della
chiocciola non dà la stessa protezione.
-- 
Fact of life #15: Heads bleed, walls don't.

 che ne dici?
beh mi pare evidente: per prima cosa gli dai uno sputtanamento pubblico 
su 
x-privat.info
 e in crosspost sui gruppi dove ha postato, poi gli 
blocchi l'accesso ovunque tranne che su x-privat.aiuto, dove se vuole 
può fare atto di costrizione e giurare che non lo farà mai più: decidi 
la penitenza (3 pater, 3 ave, 6 giorni di sospensione), poi lo 
riammetti nel gregge tenendolo d'occhio...
-- 
Sàns
...e non dimenticare la stola viola...

 tenendolo d'occhio... 
^_^ lol :)
-- 
Ciao, Dmitry

 l'ID a sinistra della chiocciola non dà la stessa protezione.
stiamo dicendo la stessa cosa :)
-- 
Ciao, Dmitry

 > (tipo quando il tuo NS è stato down)
E come fai a saperlo?  Io potrei avere 2 nick, 2 nr, accedere a 2 ns
attraverso 2 ISP differenti, ma utilizzare sempre lo stesso pseudo-FQDN.
Nulla di questo potrebbe ricondurre alla stessa persona, se non questa
informazione.
E tutto ciò potrebbe apparire, erroneamente, una violazione.
Ciao,
un TJL73 che s'augura d'aver reso l'idea...
-- 
"Essere innocenti e` pericoloso perche' non si hanno alibi."
                                                      -- Boris Makaresko

 E tutto ciò potrebbe apparire, erroneamente, una violazione.
PS: avrai una domanda da farti in privato riguardo il tuo lavoro. 
Posso chiedere qui o meglio in e-mail?
-- 
Ciao, Dmitry

 E tutto ciò potrebbe apparire, erroneamente, una violazione.
In effetti, la cosa è possibilissima!


>> utilizzare solo per invii tramite x-privat.
che però farebbe perdere l'utilità di avere un proprio fqdn da 
utilizzare ovunque. D'altra parte mi pare che se ne esca solo 
utilizzando un dominio valido da far valere presso gli abuse da cui 
provengano eventuali fake.
-- 
Sàns

 cui provengano eventuali fake.
devi tener conto di diversi fattori:
1) se assegno un FQDN valido lo faccio perchè lo si usi sul mio 
server, perchè mai dovrei far contento un utente che usa un altro 
server? Vabè buoni, ma non esageriamo :)
2) Alcuni server potrebbero non accettare MID modificati con un FQDN 
valido (non come quello di NIN per intenderci) sui loro server. Penso 
ad esempio a TIN e Mailgate, ma forse anche Wind (dovrei verificare).
3) Se uno vuole può altresì crearsi una stringa tutta sua random ed 
usa quella, che necessità ha di avere un FQDN da x-privat se poi usa 
un altro server? 
-- 
Ciao, Dmitry

 un altro server? 
Multiserver?


 Multiserver?
è il progetto che ho in mente su 
www.newsserver.it
.
-- 
Ciao, Dmitry

 3) Se uno vuole puň altresě crearsi una stringa tutta sua random
Le stringhe inventate, č stato detto piů volte che pur facendo funzionare
i filtri delproprio newsreader, non hanno alcun valore neanche
lontanamente un pochino lecito. L'alternativa sarebbe un servizio
gratuito di (pseudo)fqdn, visto che esistono 

 uno qualsiasi dei miei post 
mailgate lo ho sempre visto in modo anomalo, nel senso che non ho mai 
capito dopo Centofanti a chi sia stato affidato e come venga gestito.
-- 
Ciao, Dmitry

 Mettere l'ID a sinistra della chiocciola non dà la stessa protezione.
Allora... vediamo se riesco a fare un po' di sana confusione...  ^_^
Provo ad esprimere il concetto per come l'ho capito (o, meglio,
interpretato) io.
__
Se sono *proprietario* (termine corretto "assegnatario") di un
determinato dominio, posso utilizzare tale FQDN in qualsiasi forma,
preferibilmente, mettendo tutto l'identificativo alla _destra_ della
chiocciola.
Provo con un esempio: se il dominio che mi è stato assegnato
dall'autorità di naming, è "dominio.tld", posso (e, preferibilmente,
dovrei) utilizzare le forme "@dominio.tld" o "@ID-xxx.dominio.tld" (dove
per "ID-xxx", posso mettere *qualsiasi schifezza* mi passi per il
cervello), in modo da identificare il FQDN in modo univoco. Ciò mi è
concesso dal fatto che *qualsiasi* "sito" del dominio "dominio.tld" mi
appartiene. In tal modo, posso definire N "ID-xxx" per ciascun utente
del mio dominio/FQDN.
Questo è il caso di Dmitry. A lui (tra gli altri) è intestato il dominio
"
x-privat.org
" e quindi è formalmente autorizzato a definire ed
assegnare i vari "ID-xxx" ai suoi utenti che ne faranno richiesta.
Ciascun "ID-xxx" identificherà un "sito" del suo dominio.
A loro, verrà assegnato un FQDN (in questo caso, di terzo livello), a
tutti gli effetti valido... come fosse un nome macchina/sito.
Se non volesse sprecare N nomi di terzo livello, potrebbe assegnare
qualcosa tipo "@
ID-xxx.users.x-privat.org
". In questo modo, tutti gli
FQDN sarebbero "siti" del sottodominio "
users.x-privat.org
".
Ovviamente, prima della chiocciola, dovrà esserci la parte pseudocasuale
generata dal nr o dal ns per quel post, andando a comporre il M-ID
completo.
__
Se, invece, non sono proprietario di un dominio (come nel caso
presentato dal FQDN di Antonio), posso utilizzare un "user@FQDN", in
modo da specificare un determinato _utente_ di quel dominio (che deve
avere attinenza con quella casella di posta, virtuale o reale che sia).
In questo modo, pur non essendo assegnatario di quel dominio, posso
generare un FQDN univoco, basandomi su una casella di posta (di cui devo
essere assegnatario) di quel dominio.
Posso quindi generare, ad esempio, un FQDN con una parte a sinistra
della chiocciola e una a destra, come ad es.: "tj...@dominio.tdl", dove,
prima di tjl73, dovrà, comunque, esserci la parte pseudocasuale generata
dal nr o dal ns per quel post, per andare a comporre il M-ID completo.
__
Con questa logica, facendo riferimento ad un dominio assegnatomi, posso
utilizzare un FQDN che sia tipo "@
tjl73.altervista.org
", che andrà a
generare un M-ID tipo "
AF022.82...@tjl73.altervista.org
". Sono
/ipoteticamente/ autorizzato a fare ciò, dato che il dominio (o, meglio,
il sito) "
tjl73.altervista.org
" mi è stato formalmente assegnato del suo
titolare.
Non avendo un dominio assegnato, invece, posso quindi utilizzare un FQDN
composto da un indirizzo mail (di cui devo essere, sempre e comunque,
assegnatario), tipo "
tj...@despammed.com
", generando un M-ID con una
forma quale, ad es.: "
AF022.82A2F...@despammed.com
"
__
Quindi, per logica fin qui assunta, per poter utilizzare un FQDN tipo
"@
ID-73718.users.x-privat.org
", questo mi dovrà essere assegnato
dall'intestatario del dominio "
x-privat.org
"; mentre potrò
tranquillamente utilizzare un FQDN tipo "
tj...@x-privat.org
" senza che
mi sia assegnato dal titolare del dominio "
x-privat.org
", poiché sono
realmente assegnatario del mail address da cui questo è derivato.
Ora, però, si crea il problema relativo alla /non univocità/ di questo
secondo caso, poiché un M-ID tipo "
AF022.82A2F...@despammed.com
"
potrebbe appartenere all'utente intestatario dell'indirizzo mail
"
tj...@despammed.com
", ma anche di quello intestatario di
"
E3DA....@despammed.com
", visto che, AFAIK, non esiste una lunghezza
definita del M-ID.
__
Per concludere, come diceva Maki, l'unico modo per avere reale univocità
del FQDN, questo dovrà essere *per intero, a sinistra* della chiocciola.
Non tanto per evitare eventuali fake, quanto per evitare pseudo
duplicati dei mail address (e quindi duplicati dei FQDN). Casi rarissimi
ma non impossibili, dato che, se anche solo una piccola parte del mio
FQDN sarà a sinistra della chiocciola, potrà essere non più univoco,
venendo "assimilato" ad un qualsiasi altro FQDN/mail-address con
caratteristiche analoghe.
Beh, direi che posso anche terminare qui con il mio delirio.
Se qualcuno avesse commenti o osservazioni da fare, lo faccia ora o
taccia per sempre.  ^_^
Ciao,
un TJL73 che giura siano i peperoni e non la ganja...
-- 
"I ricercatori hanno scoperto che il cacao produce, sul cervello,
 alcuni degli effetti prodotti dalla marijuana. Hanno anche scoperto
 altre similitudini tra i due, ma non ricordano quali siano."
                                                           -- Matt Lauer

 capito dopo Centofanti a chi sia stato affidato e come venga gestito.
è di dada, e lo gestisce il Villani ^^

 taccia per sempre.  ^_^
Coincide con l'idea che mi sono fatto io :)

caratteristiche analoghe.
Lassù volevi scrivere "destra", vero?
Ciao, Alessio.
-- 
Guide e manuali su Agent: 
http://www.sleepers.it
FAQ di ICS.newsreader: 
http://faq.news.nic.it/wiki/IcsnFaq
Materiale in italiano per Agent: 
http://web.tiscali.it/agentit

del mio dominio/FQDN.
Se parliamo di FQDN in senso stretto non credo che questo sia sufficiente,
nel senso che QUALSIASICOSA.dominio non è un FQDN se non corrisponde
*realmente* ad un host. Se corrisponde invece dovrebbe andar bene.
Viceversa se decidiamo di poter usare pseudo-FQDN allora l'importante è che
il dominio ti appartenga per essere sicuro che nessuno possa usare gli
stessi tuoi nomi.
L'RFC che tratta queste cose (e non ancora obsoleta, la 1036) in effetti
richiderebbbe un Message-ID nella forma:
   <unique@full_domain_name>
dove full_domain_name corrisponde al server che ha preso in carico il
messaggio. Secondo questa definizione quindi il Message-ID dovrebbe essere
generato dal server per poter assicurare l'univocità del Message-ID.
Il senso era appunto assicurare l'univocità e per farlo si è giustamente
pensato ad un codice univoco generato dal server che prende in carico il
messaggio e con @full_domain_name l'id diventa univoco a livello globale.
Ma si sa che Internet avanza e le RFC restano indietro. Se non erro nel
"quasi standard" che andrebbe a rimpiazzare la 1036 si parla di univocità
ma senza la restrizione di cui sopra.
-- 
-antonio-
www.geminisoft.com
(email valida sul mio sito)

 è di dada, e lo gestisce il Villani ^^
così aveva detto il Villani ..
-- 
Ciao, Dmitry

 ma senza la restrizione di cui sopra.
Se lo scopo è l'univocità, dovrebbe essere sufficiente che il quel nome 
mi appartiene e non può essere usato da altri, anche se non corrisponde 
a un host, credo.


 Beh, direi che posso anche terminare qui con il mio delirio.
io sono in catalessi oggi :)
 
-- 
Ciao, Dmitry

 parla di univocità ma senza la restrizione di cui sopra.
tutto opinabile a discrezione, imho, del news-admin :)
-- 
Ciao, Dmitry

  :-))
-- 
Sàns

a un host, credo.
Lo scopo è sicuramente l'univocità anche se molti lo usano o lo vorrebbero
usare come *firma* dei propri messaggi da quello che ho capito (e sulla cui
liceità mi astengo).
Però l'argomento "non può essere usato da altri" non è tecnicamente valido
e quindi l'univocità non è garantita in quel modo, se proprio vogliamo fare
i pignoli :-)
Un modo abbastanza sicuro sarebbe quello di lasciare ai news server il
compito di generare il message-id con la forma <id@fqdn_del_news_server> e
confidando nella correttezza dei rapporti tra i server.
In alternativa esistono metodi per generare chiavi univoche pseudo casuali
con un grado di sicurezza molto alto e credo che a questo facesse
riferimento Maki (se non erro citato in questo thread) quando ha detto che
l'importante è generare la parte "sinistra" sicuramente univoca.


  :-))
direi che avessi anche un buon motivo quindi :)
-- 
Ciao, Dmitry

 rapporti tra i server. 
si ma diventa un casotto .. Applicare una regola del genere solo per 
un certo numero di utenti ... Vuol dire metter mano pesantemente con 
il perl, francamente non me la sento di buttarmi in un viaggio del 
genere per accontentare cmq un ristetto numero di utenti che vogliono 
questa feature. Io la vedo così attualmente, a chi mi fa richiesta 
genero l'ID, a sua discrezione lo userà o meno.
-- 
Ciao, Dmitry

genero l'ID, a sua discrezione lo userà o meno.
Forse non ho capito. Ma se io non genero il Message-ID tu non lo generi?


 l'importante è generare la parte "sinistra" sicuramente univoca.
Ok, per quanto riguarda la parte a sx


dal reader]
Sarebbe un errore da parte del server. Nella mia (che poi non è mia)
ipotesi il Message-ID va sempre generato dal server. Certo che se l'abusivo
è proprio il server...


 a un host, credo.
La vedo così anch'io... se io ho ricevuto (ad esempio, nel mio caso)
l'autorizzazione a "gestire" il FQDN "
tjl73.altervista.org
", posso
utilizzare quel sito per generare i miei M-ID (e nessuno, ad eccezione
di un eventuale revoca da parte di Altervista, può negarmi questo
diritto).
Ma se io fossi (e non lo sono) assegnatario, da parte della naming
authority, del dominio "tjl73.tld" potrei liberamente utilizzare
"QUALSIASICOSA.tjl73.tld" per generare i miei M-ID. Tanto, se sono
titolare del secondo livello, nessuno, ad eccezione del sottoscritto,
può generare quel "QUALSIASICOSA"; che questo sia o no presente nei
CNAME o ALIAS della zona sul DNS.
Però, potrebbe tranquillamente essere ch'io prenda un granchio.
Ciao,
un TJL73 che va avanti più per intuito che altro...
-- 
"Sono stato coinvolto in un buon esempio di contraccezione orale.
 Ho chiesto a una ragazza di venire a letto con me
 e lei mi ha detto di no."
                                                          -- Woody Allen

 Lassù volevi scrivere "destra", vero?
Sì... assolutamente... dovrei smetterla con i peperoni, vero?  ^_^
Ciao,
un TJL73 che, forse, non sono i peperoni...
-- 
Creato con Agent, il tradizionale news client di Forté
http://www.forteinc.com/agent/

 Peraltro metti a serio rischio la tua casella allo spam..
Non più che metterla nel From:, però.  ^_^
Ciao,
un TJL73 che spera solo di non diventare noioso...
-- 
"Ogni soluzione genera nuovi problemi."
                                 -- 7° corollario alla "Legge di Murphy"

 liceità mi astengo).
Mmm... a me invece interesserebbe, conoscere il tuo parere in merito,
(che mi pare di intuire che sia più contrario che favorevole)

 Cosa ne pensate?
Se io ottengo da te un FQDN vorrei poterlo usare con qualsiasi server 
NNTP.
Io quasi sempre posto con X-Privat usando l'FQDN di Individual e vorrei
poter fare lo stesso con l'FQDN di X-Privat.
-- 
Ciao, Lurkos
In case of problems with the 'Reply-To' address, please write me to  
yhexbf _qbg* hfrarg [ng) k /qnfu\ cynarg *qbg_ bet (use ROT-13).

(che mi pare di intuire che sia più contrario che favorevole)
I post fatti da me sono facilmente identificabili dall'header "From". Per
seguire le risposte ai miei messaggi è sufficiente un "follow thread" del
messaged-id del messaggio, non importa in che forma esso sia scritto.
Quindi in questo senso tutto l'ambaradan creato attorno alla creazione del
message-id *firmato* mi sembra esagerato.


 message-id *firmato* mi sembra esagerato.
In certi casi può essere utile averlo.


 In certi casi può essere utile averlo.
Inoltre, a volte interessa  marcare diversamente i propri messaggi e le 
risposte ricevute, e non con il generico Watch  che si usa anche per 
altre ragioni.


altre ragioni.
Ho capito, qualcosa per marcare i thread delle risposte ai tuoi messaggi in
modo diverso. 
Dipende, credo, dalla potenza dei filtri del programma. Con un filtro ad
hoc per le risposte ai tuoi messaggi puoi seguire la conversazione e
marcarla come preferisci e poi avere un altro filtro per seguire le altre
discussioni.
Ma con programmi con filtri meno potenti in linea di massima un Message-ID
firmato rende più semplice l'operazione, concordo.


 FQDN e lo utilizzi per puntare ad un server. 
spero :)
-- 
Ciao, Dmitry

 vorrei poter fare lo stesso con l'FQDN di X-Privat.
proprio per questi motivi sono qui a discuterne con voi, per capire 
la soluzione ottimale, perchè una volta che poi ho deciso non voglio 
tornare sui miei passi :)
-- 
Ciao, Dmitry

 vorrei poter fare lo stesso con l'FQDN di X-Privat.
azz, leggo solo ora. Uso l'ID di NIN con X-Privat!!!!! 
Blasfemo!!!!!!!!!!!!!! radiazione dall'albo deggli x-privatisti :)
-- 
Ciao, Dmitry

 generi? 
se lo generassi dovrei sovrascrivere il tuo, il che non è nella mia 
policy. Viene fatta solo una verifica di sintassi, in praticolare che 
siano presenti nella forma corretta '<' '>' e '@' \. etc
-- 
Ciao, Dmitry

siano presenti nella forma corretta '<' '>' e '@' \. etc
OK, ma io mi chiedevo nel caso in cui io NON generassi il Message-ID.
L'articolo verrebbe rifiutato?


 Message-ID. L'articolo verrebbe rifiutato?
se il newsreader non genera il MID lo fa x-privat di default, ovvio.
Ma forse ancora non ho capito cosa intendi dire? se viene generato un 
mid del tipo @
kkasks.id
 senza nulla prima della chiocciola, viene 
rifiutato
-- 
Ciao, Dmitry

 Però vuole redimersi :D
e così sia ! :)
-- 
Ciao, Dmitry

 e cosģ sia ! :)
suvvia, parlatene in X-privato :-PPP

 suvvia, parlatene in X-privato :-PPP
lol :)
f/up
-- 
Ciao, Dmitry

rifiutato
No, no... chiedevo la cosa ovvia di cui sopra :-)


 No, no... chiedevo la cosa ovvia di cui sopra :-)
si beh, ci mancherebbe che non generasse un MID! :) Peraltro le 
regole che determinano anche quali MID accettare e quali no sono 
molto complesse. Portare alt.sex ed alt.binaries (in parte) significa 
perfezionare quanto più possibile le regole di filtraggio in quanto 
ti espone a innumerevoli problematiche.
una delle tante..
# Message-ID considerati fonte di possibile spam
$invalid_message_id = 
"\@netnews\.hinet\.net|\@nntp\.net\ru|\@mailinator\.com"
if (rexp("message-id",$invalid_message_id )) reject "Article Refused: 
Invalid Message ID"
# se il messaggio non è destinato ad un gruppo binario il limite è di 
# 125 Kbytes
   if (!matchall("newsgroups",$bin_allowed)) then
      if (size()>125000) reject "Article Refused: Post cannot larger    
\	than 125KBytes "
   end if
18 kb di rules ..
-- 
Ciao, Dmitry

 Beh, direi che posso anche terminare qui con il mio delirio.
Va beh. :-) Sarò onesto, non ho letto tutto in dettaglio, a un certo punto
mi son perso, ma fa lo stesso. Il problema IMHO è che ci si fanno troppe
pere mentali sui massimi sistemi e non si guarda al lato pratico delle
cose.
Guardiamo alla pratica: c'è l'esigenza di generare M-Id sintatticamente
validi, ma che contengano "qualcosa" di tracciabile dai filtri evitando
falsi positivi e duplicati.
stringa...@user-id.server è sintatticamente valido.
"user-id" è facilmente tracciabile da quelli come me che assegnano uno
score progressivamente decrescente alle risposte che riceve.
Se la "stringacasuale" è realmente casuale (non vedo perché dubitarne) non
ci sono duplicati.
I puristi obiettano che user-id.server non è presente nei DNS quindi a
rigore non è un FQDN. Va bene, ma son pere mentali. I DNS non sono
coinvolti nella gestione dei M-ID o delle references. L'unico a potersi
lamentare di questo uso è l'assegnatario del dominio: ma se questi
autorizza la cosa il problema non esiste.
Inoltre se l'assegnatario del dominio mi attribuisce un user-id, nel
momento in cui qualcun'altro prova ad usarlo, per dolo o per sbaglio,
l'assegnatario del dominio ha diritto di farlo smettere (o quantomeno di
provarci nei limiti del possibile), visto che non è autorizzato. Se si
mette l'user-id a sinistra della chiocciola questo diritto vien meno.
Dunque i falsi positivi sono evitati, a meno che uno non lo faccia apposta.
In totale IHMO la soluzione ideale è che:
a) il postmaster assegna un ID a ogni utente
b) l'utente viene autorizzato a usare *in un determinato modo* questo ID
   se genera il M-ID tramite il suo NR (anche postando da un altro server)
c) se il NR non genera il M-ID lo fa il server, inserendo l'ID se richiesto
   dall'utente al momento dell'iscrizione o in altra sede. Di default non 
   viene inserito per questioni di privacy.
Il punto c (sempre che sia tecnicamente possibile) è per venire incontro a
chi usa NR che non permettono all'utente di controllare la generazione del
M-ID, ma che potrebbero beneficiarne a livello di filtri.
Volendo esagerare ci sarebbe anche:
d) opzionalmente l'utente può chiedere che il proprio ID venga
   "certificato" dal server. Cioè il server inserisce il mio ID solo previa 
   autenticazione. In questo modo si è sicuri che un post inviato 
   tramite quel server *e* contenente il mio ID è stato spedito da me.
   Nel caso di un attacco di NTO e simili è facile per chiunque verificare
   la reale provenienze di un post sospetto, visto che l'attaccante può
   usare il mio stesso ID *o* il mio stesso server, ma non entrambi.
-- 
Fact of life #15: Heads bleed, walls don't.

    ID *o* il mio stesso server, ma non entrambi. 
ok, mi sono stufato. Famo 'na cosa. Chi vuole il suo MID 
personalizzato da domani mi manda la sua chiave PGP e io ci firmo 
automaticamente i messaggi, va bene? :)
bando alle ciancie, ci stiamo davvero facendo delle pere mentali.
 
-- 
Ciao, Dmitry

 automaticamente i messaggi, va bene? :)
Mi auguro tu stia scherzando...   O_o !?!?!
Ciao,
un TJL73 che la prende come una battuta ironica...
-- 
** NOTE: This message is ROT-13 encrypted twice for extra protection **

 Mi auguro tu stia scherzando...   O_o !?!?!
ci mancherebbe
-- 
Ciao, Dmitry

 Blasfemo!!!!!!!!!!!!!! radiazione dall'albo deggli x-privatisti :)
Beh ... che c'è di male?
Uso sempre X-Privat per spedire i post perché copre tutti i NG che 
seguo ed è indipendente dalla connessione.
Mi ero però iscritto prima ad Individual quasi esclusivamente per avere 
l'FQDN da impostare in Hamster (per poi tracciare le risposte ai miei 
post).
Se Individual non avesse offerto l'FQDN e se non fosse stato citato 
nella stessa guida di Hamster molto probabilmente non mi sarei neanche 
iscritto.


    il mio stesso server, ma non entrambi.
Uh?
*X-Privat* richiede sempre l'autenticazione.


 sarei neanche iscritto.
si ma stavo scherzando eh :) Non devi giustificarti, ci mancherebbe 
:) Be happy :)
-- 
Ciao, Dmitry

 *X-Privat* richiede sempre l'autenticazione.
Io parlavo di mettere qualcosa negli header che possa essere inserito
*solo* dal server e non forzato da un eventuale fake, in modo che chi legge
possa verificare l'autenticità dell'autore (senza "sporcare"il post on PGP
e simili).


 :) Be happy :)
Bene :)
Cmq puoi vedere l'importanza che può avere uno pseudo-FQDN per gli 
utenti più smaliziati ...


 gli utenti piů smaliziati ...
adesso sto facendo dei lavori importanti per l'utenza non italiana, 
finito questo attivo subito la richiesta di FQDN :)
-- 
Ciao, Dmitry

 (senza "sporcare"il post on PGP e simili).
Se non vuoi rischiare che ci sia qualche fake basta che usi *X-Privat*, 
visto che aggiunge X-Authenticated-User.
Non hai bisogno di alcun (pseudo-)FQDN.
IMHO l'FQDN non serve per questi casi, ma per poter generare Message-ID 
in locale con dominio valido per facilitare lo scoring.


 finito questo attivo subito la richiesta di FQDN :)
Vai pure tranquillo :)


 scoring. 
su questa argomentazione è nato un threaddone infinito :)
-- 
Ciao, Dmitry

 visto che aggiunge X-Authenticated-User.
Parlavo in generale. IMHO sarebbe una bella cosa poter certificare la
provenienza dei post. Sempre preservando la possibilitą di postare
"anonimamente" per chi lo desidera.


 possibilità di postare "anonimamente" per chi lo desidera.
certificare in che senso? spiegati, non ho afferrato ;)
-- 
Ciao, Dmitry

 certificare in che senso? spiegati, non ho afferrato ;)
Nemmeno io.
Più certificato di così non si può ...
Se proprio vuoi essere (pseudo-)anonimo puoi usare Aioe.


 su questa argomentazione è nato un threaddone infinito :)
Già ...


 Se proprio vuoi essere (pseudo-)anonimo puoi usare Aioe.
è quello che consiglio sempre io ma nessumo mi ascolta :)
PS:
scusa Paolo ma te la meriti ogni tanto la sculacciata :)
-- 
Ciao, Dmitry

 scusa Paolo ma te la meriti ogni tanto la sculacciata :)
???


 ???
mi riferivo ad AIOE :)
-- 
Ciao, Dmitry

 mi riferivo ad AIOE :)
Sě, avevo capito che ti riferivi ad Aioe, ma non avevo capito il senso 
della tua battuta :)


 senso della tua battuta :)
lol :) lui si perň, in effetti poteva capirla solo lui.
-- 
Ciao, Dmitry