Newsgroup: it.comp.software.newsreader
Titolo: Generazione del Message-id

Qualcuno mi sa spiegare in italiano chi e come genera il Message-id?
Fin'ora l'unica cosa che ho capito con ragionevole certezza è che i
miei contengono il mio indirizzo e-mail, ma mi piacerebbe saperne di
più per affinare lo scorefile.
TIA.
-- 
Fact of life #15: Heads bleed, walls don't.

Qualcuno mi sa spiegare in italiano chi e come genera il Message-id?
C'è stato un thread un po' di tempo fa, prova a cercare con Google.
Comunque il message-id lo dovrebbe generare il newsreader, è composto
da due parti unite con una "@". Generalmente la prima parte è un
numero casuale, la seconda è il nome del news server, con alcuni
newsreader comunque puoi personalizzare queste impostazioni.
Se non sbaglio c'è stata anche una proposta di RFD su come
standardizzare i message-id, ma non ricordo esattamente.
-- 
Marco Barisione (ICQ 84277092)

 newsreader comunque puoi personalizzare queste impostazioni.
L'avevo letto, ma e' teorico.
Spiego meglio quel che mi interessa: per pura osservazione credo di
aver determinato che MacSoup e YA-NewsWatcher mettono una stringa
casuale seguita dall'email di chi spedisce, mentre MT-NewsWatcher mette
l'username, poi roba casuale. Agent, mi pare metta una stringa casuale
seguito da @
4ax.com
, OE non mette nulla quindi lo fa il server.
Però vedo anche che il server crucco sovrascrive i message-id degli
utenti Agent, dunque deduco che e' possibile il fallimento dei criteri
di cui sopra. D'altra parte il server crucco mette uno user-id ai post
per cui qualcosa su cui filtrare cmq resta.
Domanda 1: in quali e quanti casi i server cambiano i message-id?
Domanda 2: io cerco il mio indirizzo nei reference per attribuire uno
score positivo alle risposte che vengono date ai miei post. Posso
consigliarlo ad altri utenti di YA-NW o è probabile che fallisca a
causa del server?


    <-- 2 scelta
->NON ABUSARE gli "abuse desk", segnala solo lo spam e il vero netabuse<-      

per cui qualcosa su cui filtrare cmq resta.
Per quello che so io (lettura delle RFC) dovrebbe essere il server a
generare il message-id per poter garantire l'univocita'. In effetti si
parla del server che immette il messaggio sulla Rete. Il nostro Pimmy, di
cui io sono uno degli autori, non genera il message-id e lascia la palla al
server. E' piu' facile e forse e' anche la cosa giusta :-)
-- 
-antonio-
www.geminisoft.com




tutto vero,  in questo  caso pero`  diventa cruciale  fare particolare
attenzione  a mettere tutti  controlli per  evitare  di  mandare copie
multiple dello stesso articolo, come faceva outlook.


fidarsi.
Io ho trovato 
http://www.jwz.org/doc/mid.html
 sulla generazione dei
message-id, da cui:
|In summary, one possible approach to generating a Message-ID would be: 
|- Append "<". 
|
|- Get the current (wall-clock) time in the highest resolution to which 
|you have access (most systems can give it to you in milliseconds, but 
|seconds will do); 
|
|- Generate 64 bits of randomness from a good, well-seeded random 
|number generator; 
|
|- Convert these two numbers to base 36 (0-9 and A-Z) and append the 
|first number, a ".", the second number, and an "@". This makes the 
|left hand side of the message ID be only about 21 characters long. 
|
|- Append the FQDN of the local host, or the host name in the user's 
|return address. 
|
|- Append ">".
Questo metodo mi pare buono, conoscete link a pagine che illustrino i
metodi usati dai newsreader più diffusi?


 server. E' piu' facile e forse e' anche la cosa giusta :-)
Io non so se č la cosa giusta, ma poter contare su un riferimento fisso
nel Message-ID farebbe fare enormi passi avanti nel killfilteraggio.
Immagina che il PPisquano inizi a usare Pimmy. Non ti sentiresti piů
buono sapendo che il mondo puň evitarlo automaticamente assieme a 
tutte le risposte che riceve? :)


nel Message-ID farebbe fare enormi passi avanti nel killfilteraggio.
No, io credo che i server non dovrebbero fidarsi del message-id creato dai
client.
-- 
-antonio-
www.geminisoft.com

client.
Molti criticano OE perché non genera i message-id, c'è un motivo
sensato per questo o è giusto per criticare OE?


client.
Attualmente esistono client che generano message-id male?


Attualmente esistono client che generano message-id male?
Non lo so ma se vuoi modifico Pimmy :-)
-- 
-antonio-
www.geminisoft.com

E perche` mai? :-/
1. Perche' io client potrei generare dei message-id non univoci per errore;
2. Perche' io client potrei generare dei message-id univoci per me ma che
poi si scoprono non univoci quando arrivano sul server oppure sugli altri
server
3. Perche' l'rfc 1036 (vedi mio altro post) dice che il message-id deve
contenere il nome dell'host che fa entrare il messaggio sulla rete, ovvero
il server. A questo punto il client dovrebbe generare il message-id usando
l'host del server che sta usando per la spedizione... ma come puo' sapere
l'algortimo usato dal server per generare ID univoci?
-- 
-antonio-
www.geminisoft.com

sensato per questo o è giusto per criticare OE?
Secondo me non c'e' nessun motivo. Il message-id deve essere creato dal
server perche' solo lui puo' creare un message-id univoco all'interno del
"dominio dell'host attraverso il quale il messaggio entra nella rete".
[rfc 1036 - Usenet messages]
In order to conform to RFC 822, the Message-ID  must  have
the format
     "<" "unique" "@" "full domain name" ">"
where  "full domain name"  is the full name of the host at
which  the article entered the network, including a domain
that host is in, and unique  is  any  string  of  printing
ASCII  characters,  not  including  "<", ">", or "@".
-- 
-antonio-
www.geminisoft.com

 generare ID univoci? 
Veramente, secondo la stessa RFC1036 l'unicità del msg-id non è 
affatto necessaria...
Comunque generare un msg-id non è difficile, e poiché è una feature 
che può risultare utile in varie occasioni[1], imho un buon nr 
dovrebbe avere la possibilità di farlo.
[1] Non solo per il filtraggio. Ad esempio, se mi accorgo che il 
newsserver che uso è isolato (nel senso che non propaga gli articoli), 
posso fare un repost da un altro server, senza generare doppioni.
-- 
Ciao, Marvin

" docet :-)
Io sto parlando di RFC, quello che poi si fa nella realta' e' un'altra
cosa. Siccome qualcuno ha tirato fuori che OE sbaglia...
-- 
-antonio-
www.geminisoft.com

piu` messaggi vengono inviati nello stesso nanosecondo) 
Non e' affatto vero. La generazione del message-id non e' necessaria e anzi
secondo me e' addirittura da non fare. Sempre che non abbia mal
interpretato le RFC.
Pimmy non genera il message-id e tutto funziona perfettamente.
-- 
-antonio-
www.geminisoft.com

dovrebbe avere la possibilità di farlo.
Non e' questione di difficolta'. Windows ha una funzione che genera un ID
univoco senza nessun problema. Non e' questo il punto. C'e' chi usa le RFC
come bibbia quando OE non fa le cose bene ma mi sembra che quando le cose
sono fatte come dicono le RFC... allora le RFC si possono "interpretare".
Senza polemica verso di te, naturalmente.
-- 
-antonio-
www.geminisoft.com

interpretato le RFC.
In effetti ho riletto la RFC e non mi pare specifichi chi deve
generare il message-id.
Comunque collisioni di message-id sono difficili ma se ci fossero
(magari intenzionalmente)? Cosa succederebbe?


(magari intenzionalmente)? Cosa succederebbe?
Il message-id puo' essere usato nelle interrogazioni NNTP per accedere ad
un messaggio. Se due sono uguali...
Ci sono cose peggiori nella vita, naturalmente :-)
-- 
-antonio-
www.geminisoft.com

(magari intenzionalmente)? Cosa succederebbe?
'441 posting failed' causato da '435 article not wanted - do not send it'.
-- 
Bye,
Alfredo Amontagna

 cosa. Siccome qualcuno ha tirato fuori che OE sbaglia...
*non* e`  vietato da nessuna parte al   client generare il Message-ID,
quindi non  si  viola   proprio  nessuna  delle RFC.     E   immettere
correttamente il  Message-ID  secondo l'algoritmo suggerito   da Marco
(che  e` quello  giusto)  e` possibile anche  dal client  usando nella
parte destra il reverse lookup dell'IP, anche dinamico, assegnato alla
macchina (oopure  l'IP stesso) e  nella parte sinistra  data e nummero
pseudocasuale (per  esempio il process ID).   Nel caso  si supporti la
lettura offline basta che il posting agent assegni l'ID al momento del
dialogo  NNRP col server.   L'univocita`  e` garantita perche` non  ci
saranno mai due  computer con  lo stesso  IP  che postino allo  stesso
momento.   Esiste la   possibilita` *teorica*  che  orologi di  client
settati male consentano una idntita` al *secondo* , ma la probabilita`
che vi si  associ anche il  numero pseudocasuale e`  talmente bassa da
non costituire un problema.
Assegnare l'ID dal lato  client   introduce un livello di    sicurezza
contro   eventuali bug nella  gestione dei  problemi di connessione, i
quali potrebbero portare ai post multipli.
Sono   due  scuole di  pensiero,  e  valutando i pro  e   i contro gli
sviluppatori  fanno la loro scelta.  Io  penso che la soluzione giusta
sia quella di lasciar fare al server, ma  bisogna essere molto attenti
ad inserire  controlli  giusti  per  evitare di  floodare  usenet, che
sarebbe molto  peggio che generare  un message-id non univoco  ogni 10
miliardi di post.


 affatto necessaria...
certo  che lo e`.  Anzi l'intera   architettura di  Usenet si  basa su
questo. Non c'e` nulla di piu` importante.





no, non  viene  criticato per questo, almeno   non  da chi conosce  il
problema con sufficiente  profondita`.  Basarsi  *solo* sul Message-id
per evitare il multipost e` una scelta progettuale sbagliata.  Ci sono
altri sistemi che si possono seguire.
Per esempio, Tin  di default non  assegna il Message-id, hai mai visto
post multipli provenienti da Tin?
Outlook mancava in questo genere di controlli.





che  andrebbero in giro articoli  diversi con lo  stesso  ID, e questo
comporterebbe serissimi problemi di propagazione per tutti, sarebbe un
disastro, le cui proporzioni sarebbero direttamente proporzionali alla
frequenza di tale evento.  Bisogna  ricordarsi che  i server prima  di
accettare un articolo dai propri peer o  dai propri client controllano
*sempre* l'history.
Teoricamente uno spoofing  del Message-ID potrebbe servire ad impedire
la propagazione di  un articolo. Mi meraviglio  ancora che gli spammer
non lo abbiano mai utilizzato  (per esempio hipcrime che pare  dedichi
la sua intera   esistenza a rompere le   balle  su Usenet non ha   mai
pensato ad un semplice   spoofing  dei cancel  per prevenire   la loro
propagazione).


 Saluti :-)
fatti un giro su it.news.gcn :-)


propagazione).
Questo vorrebbe però dire conoscere il msg-id del messaggio da
bloccare prima che questo si sia propagato e se è già presente in
molti server è difficile che il proprio messaggio "killer" si propaghi
meglio di quello originale.


questo. Non c'e` nulla di piu` importante.
La RFC però dice che il msg-id non andrebbe riutilizzato prima di due
anni almeno, quindi un server potrebbe benissimo assegnare dei
message-id con numero sequenziale e poi dopo due anni ripartire
dall'inizio e rispetterebbe la RFC.


un messaggio. Se due sono uguali...
Era proprio a questo che mi riferivo, inizio a pensare che siano OE e
Pimmy a comportarsi correttamente.


Uso da una vita programmi che lo generano e tutto funziona alla grande 
Che ne sai, magari qualcuno non ha visto un tuo post perché il tuo
programma ha generato un message-id uguale a quello generato da un
altro utente :-)


 anni almeno, quindi un server potrebbe benissimo assegnare dei
Non nell'ultimo draft e comunque dubito che sia un buon algoritmo. 


 meglio di quello originale.
Certo, ma io  mi riferivo al blocco dei  cancel per i quali esiste  la
convenzione $alz che ne regola la formazione del message-id, quindi lo
spoofing sarebbe banale.


 un'altra cosa. Siccome qualcuno ha tirato fuori che OE sbaglia...
OE non sbaglia quando manda articoli senza msg-id, OE sbaglia quando 
manda copie multiple dello stesso articolo.
Per evitare di spacciare n articoli uguali e diversi, l'astuto 
programmatore di OE avrebbe potuto seguire due strade:
 - evitare di inviare le copie successive alla prima;
 - mettere lo stesso msg-id a tutte le copie, cosě che
   solo la prima venga accettata.
-- 
Ciao, Marvin

 le RFC si possono "interpretare". 
Per me è sicuramente così.
Non mi importa nulla se un certo programma vìola un certo comma di una 
certa RFC, se ciò non provoca alcun danno alla comunità. (E ancor più 
quando tale comportamento è entrato da anni nella prassi corrente.)
-- 
Ciao, Marvin

 su questo. Non c'e` nulla di piu` importante.
La RFC1036 raccomanda di non riutilizzare i msg-id per almeno 2 anni. 
Un comodo passaggio logico implicherebbe che riutilizzare i msg-id 
dopo 3 anni sarebbe lecito. So long all'unicità, quindi...
NB: non sto dicendo che l'unicità non sia importante, anzi 
fondamentale; l'esempio serviva a dimostrare che, come nel caso dei 
msg-id assegnati dal nr, il mondo non inizia e non finisce nelle RFC.
-- 
Ciao, Marvin





Infatti, "il mondo" inizia e finisce  nelle convenzioni che permettono
di comunicare, convenzioni  che nel tempo  evolvono.  Le rfc sono solo
un tentativo di raggrupparle e  spiegarle per il pubblico beneficio, e
anche esse quindi tendono a diventare  obsolete.  La 1036 e` forse una
delle piu` obsolete che si trova in giro.
Il nuovo draft non a caso dice:
|  Following the provisions of [RFC 2822], an agent generating an
|  article's message identifier MUST ensure that it is unique and that
|  it is NEVER reused (either in Netnews or email). Moreover, even [..]


 quando tale comportamento è entrato da anni nella prassi corrente.)
sono ben poche le violazioni degli standard che non portano danni alla
comunita`. Anzi  mi piacerebbe se me ne   elencassi qualcuna visto che
non me ne vengono proprio in mente.


 - evitare di inviare le copie successive alla prima;
non e`  cosi` banale, per  esempio che  cosa dovrebbe  fare un posting
agent se ha   appena   inviato l'articolo   e non   ha   ricevuto l'ok
dall'injecting agent  per un qualsiasi  problema?  L'articolo potrebbe
essere stato  passato  e lui non  ha  modo di saperlo.  Quindi dare un
messaggio di errore all'utente, aspettare, oppure rimandare l'articolo
sono tutte scelte che potrebbero dare dei problemi.


 l'algortimo usato dal server per generare ID univoci?
Basta e avanza quanto hai scritto per concordare con te, ma evidentemente 
per chi vuol fare solo polemica la logica non conta.
Ciao e buon lavoro.
-- 
Chi disprezza la propria vita, tiene in pugno quella degli altri.
Seneca

 manda copie multiple dello stesso articolo.
Lo "sbaglio" e' in massima parte attribuibile al server e solo per la parte
restante attribuibile a chi utilizza OE.
Comunque se ne vedono sempre meno di articoli multipli, segno questo che
i server sono gestiti meglio e gli utenti di OE stanno piu' attenti.
-- 
Ciao, Piero

spoofing sarebbe banale.
Ma non c'è nessuna RFC che obbliga al rispetto di questa convenzione
(cioè il cancel message ha come id "cancel." + il msg-id del messaggio
da cancellare) o sbaglio? Un server può accettare senza problemi
cancel message che nno seguono la convenzione $alz?


cancel message che nno seguono la convenzione $alz?
Sě, visto che sono quelli spediti normalmente dalle persone.
Forse bisognerebbe fare il contrario, ma vedo difficile fare in modo che
finisca in typhoon.
-- 
ciao,
Marco

 cancel message che nno seguono la convenzione $alz?
i server che  accettano  i  cancel non stanno   a guardare  se  questi
seguono  la  convenzione $alz,  infatti  o  si accettano  tutti   o si
bloccano tutti.  Il problema e`  dei cancelbot che dovrebbero smettere
di seguirla nel caso in cui uno spammer un po' meno stupido del solito
facesse  due piu` due senza sbagliare  di troppo il risultato, creando
cosi` una ulteriore ridondanza in   un traffico che neanche   dovrebbe
esistere  (in altre parole   per ogni  spam che  supera  il   BI=20 ci
sarebbero  n articoli che  vengono processati da  una   larga fetta di
Usenet, con n uguale al numero di cancelbot attivi + 1).
Il punto e`  che  la cancellazione da  terzi  e` uno sporco  hack  che
andrebbe  abbandonato in  favore   di  alternative gia` presenti   sul
"mercato" da tanto tempo.
(*) per esempio, la rfc 2635 (don't spew) di fatto autorizza l'opt-out
(**)Il   punto e` che  le  rfc  sono  sottoposte  ad un peer reviewing
    da parte di esperti del settore provenienti dal mondo accademico e
    dell'industria  esattamente  come  avviene   per  le pubblicazioni
    scientifiche  e  questo garantisce    e  spinge verso   un livello
    qualitativo spesso adeguato e comunque unico nel suo genere.


 visto che non me ne vengono proprio in mente.
  La regola sul full domain name;
  quella secondo cui l'header References deve essere omesso quando il 
  Subject cambia[2];
  il fatto che un nr riconosca in " >" un simbolo di quoting o in "--\n" 
  un separatore di firma;
sono i primi esempi che mi vengono in mente di RFC che sono 
regolarmente violate dai nr, senza che nessuno ne abbia mai avuto 
alcun danno.
[1] The Message-ID must have the format: <unique@full_domain_name> 
    where full_domain_name is the full name of the host at which the 
    message entered the network
[2] [The 'References' header] is required for all follow-up messages, 
    and forbidden when a new subject is raised
-- 
Ciao, Marvin

 alcun danno.
questo lo dici  tu.  La leggibilita` di  un articolo e` cosa altamente
auspicabile e  questi  semplici standard  permettono una formattazione
automatica sia  in  apertura di thread  che, sopratutto,  in f/up, che
aumenta   di gran  lunga  la qualita`  di quello   che si introduce su
Usenet.   Una delle  colpe maggiori di   outlook  e` proprio su questo
fronte.
+++
Ascolta io non voglio metterti in bocca parole che non hai pronunciato
per cui  faccio un discorso generale  che nella frase  seguente non si
rivolge a te ma che trae solo spunto da alcune tue frasi.
Gli standard esistono e sono qui per rimanere e con  loro si deve fare
i conti.   Chi vuole puo` facilmente reperirli e informarsi, almeno se
vuole scrivere del software di buona qualita`.  Andare a scavare nelle
rfc per trovare contraddizioni  o verita` oggi sorpassate per sminuire
il valore degli accordi comuni e`  semplicemente molto sciocco.  Farlo
poi per un   attaccamento da stadio ad  un  software con  le  finestre
colorate  che pero` non rispetta  tali standard, per superficialita` o
per politica aziendale che dir si voglia, e  che nel fare questo causa
disagi al resto del mondo (e il delimitatore di firma non standard per
esempio non  uccide Usenet ma   causa grandi disagi)  e` semplicemente
assurdo.


metodi usati dai newsreader più diffusi?
Agent:
http://groups.google.com/groups?ic=1&q=msgid:%3Cp4mdur0hqesigvi9niom2och7liu6fqqeg%404ax.com%3E
-- 
Ciao, Massimo | ICQ# 57669970 | Per scrivermi togli .com
- Salviamo i plancton, a morte le balene! -

Il nuovo draft non a caso dice:
Dove posso trovare questo draft?


 "Carlo Fusco" wrote:
<cut>
mi e' arrivata una email il cui messageID era formato da oltre
100 caratteri, esclusa chiocciola e dominio,
non e' un po' troppo lungo?
era del server di libero.

Dove posso trovare questo draft?
http://www.ietf.org/internet-drafts/draft-ietf-usefor-article-06.txt
News Article Format
<draft-ietf-usefor-article-06.txt>
5.3.  Message-ID

Non esistono programmi senza errori.  
 
         ? 
     `  _ ,  ?
    -  (o)o)  -
---ooO-'(_)--Ooo---
E Pimmy?
<con gli occhioni sbarrati come un bambino che sente dire che che Babbo
Natale non esiste>   :-)
Ciao.

 Dove posso trovare questo draft?
http://www.tin.org/docs.html
 e lo cerchi fra i vari documenti.



http://www.tin.org/docs.html
 e lo cerchi fra i vari documenti.
mi ha incuriosito questo:
Reply Posting Guidelines in One to Many Communications
parla del quoting sopra o/e sotto, vero?



si` ed e` un mucchio disordinato di idee confuse  e ignoranza.  Grazie
al processo  di peer reviewing della IETF  si spera che quell'obrobrio
non verra` mai pubblicato.
A proposito, ho  aperto un concorso,  offro cinque  birre da consumare
alla prima occasione (se mai ci sara` di  cena di newsgruppo) a scelta
a    chi mi  trova    le  tre cazzate  piu`   grosse  scritte  in quel
documento. Per chi volesse partecipare ho aperto un apposito thread su
it.cultura.cybersocieta. Un  bonus  di altre 5 birre   al primo che mi
trova  la cazzata piu` macroscopica   dal punto di vista  strettamente
tecnico della cultura e del funzionamento di Usenet.


 ad un messaggio. Se due sono uguali...
Se un news server riceve un articol con un messagge ID uguale ad uno che
ha già rifiuta l'articolo con un bel duplicate. D'altra parte *credo* che
funzioni così anche la storia di avere più feed, vengono rifiutati da un
feed gli articoli che si hanno già controllando in message-id.
-- 
Veneziano Davide (
ve...@vene.ws
)
http://www.vene.ws
  Faq e manuali, Servizi Internet
http://mail.vene.ws
 E-mail Gratuite Pop3/Smtp/Web
ICQ# 14047537


http://www.tin.org/docs.html
 e lo cerchi fra i vari documenti.
Grazie mille a te ed a Cataldo :)
Curiosita`: questo draft dovrebbe divenire prima o poi una rfc,
giusto? Quanto tempo, presumibilmente, occorrera`?
Tra l'altro, ho dato un'occhiata molto veloce al documento, ed ho
letto:
|   Internet-Drafts are draft documents valid for a maximum of six
|   months and may be updated, replaced, or obsoleted by other
|   documents at any time. It is inappropriate to use Internet-Drafts
|   as reference material or to cite them other than as "work in
|   progress."
Mi pare che sei mesi siano passati da quando e` stata scritta
(novembre 2001)...
