De los archivos de CIUB-L

Date:         Fri, 13 Jun 1986 23:56:06 ABC
Sender:       (ZCCBJBC@EB0UB011) via List Processor <LlSTSERV@EB0UB011>
Reply-to:     Distribution List <ZACUCIUB@EB0UB011>
From:         Jose Maria Blasco Comellas <ZCCBJBC@EB0UB011>
Subject:      Ja tenim un LISTSERVer
Comment:      Miguel Angel Campos <ZCCBMCL@EB0UB011>

Una explicacio mes o menys caotica de LISTSERV (i MAILER)
*********************************************************

  Si mireu la capcalera d'aquest MAIL veureu que es diferent de la dels
altres MAILs que heu rebuto Apart de uns quants camps mes o menys
criptics que ja explicare, una cosa important es que ja no surt,
a cada nota, la llista de tots els receptor s (Aixo millora la
ocupacio del spool). Si a algu no li agrada el nom que te, que
m'ho digui.

  LISTSERV es una maquina desconectada de servei, amb el codi
arribat per la xarxa desde INFO@BITNIC. Serveix per a racionalitzar
i automatitzar les llistes de distribucio:

Tres metodes per gestionar llistes de distribucio:
--------------------------------------------------

  Una llista de distribucio es una mena de discussio electronica.
  Hi ha una serie de persones, interessades en un tema, que volen
  comunicarse electronicament; cada una diu el que pensa, contesta el
  que va dir un altre, fa una pregunta, pontifica o el que sigui.
  I tots els membre de la llista tenen una copia de tot el que estan
  dient tots els altres membres de la llista (En aixo es distingeix una
  llista de distribucio de una estructura jerarquica [p. ex., una
  llista de consultas] on tothom parla amb una sola persona, que
  contesta nomes a qui ha preguntat).

    Per montar una llista hi ha essencialment tres metodes:

  1.- Cada persona te (p. ex. al seu NAMES) la llista de totes les demes
      persones, i cada cop que vol dir algo ho fa a tota la llista.

      Aixo pot anar be si el grup es reduit i fixe (els seus components no
    cambian casi mai), pero sino te varias pegas: si algu s'afageix o es
    suprimeix, cal que *cada un* dels membres de la llista modifiquin
    la seva copia de la llista de integrants; aixo sol donar problemes
    (la gent s'oblida de fer-ho, i el nou membre perd MAlLs o un antic
      membre segueix rebent-ne).

  2.- Hi ha una persona que ho centralitza tot (com feia jo fins fa poc
      amb las llistas CIUB i EXEC).

      Aixo te la ventatja de que aixi els components de la llista no
      necessiten saber qui mes hi ha a la llista, pero es pesadissim per a
      l'administrador, que s'ha de encarragar de re-enviar cada MAlL a
      tothom, l'hagi generat ello no; a mes, els camps de la nota
      queden complicats amb linies 'Resent-To' i demes. A mes, les
      capcaleres del MAILs son molt sovint llarguissimes (mes que el texte
      del missatge), i sembla que el que ho controla tot pugui fer trampa
      (o equivocarse) i cambiar el contingut deIs missatges (aixo pot estar
      be, d'altra banda, per a llistas amb el que s'anomena un 'Editor', que
      fa justament aquesta funcio).

  3.- S'utilitza LlSTSERV.


Un esquema de com funciona LlSTSERV (amb l'ajut de MAlLER)
----------------------------------------------------------

                                                               +------------+
                        +----------+ ------------------------> | Receptor 1 |
   +------------------> |  MAILER  | --------------------+     +------------+
   |                    +----------+ <-+--+-----+        |           .
   |                           |       |  |     |        | (4)       .
   |                           |       |  |     |        |           .
   |                           |       |  |     |        |     +------------+
(1)|                       (2) |       |  | (3) |        +---> | Receptor n |
   |                    `      |       |  |     |              +------------+
   | MAIL                      |       |  | ... |
   |                           V       |  |     |
+-----------+               +----------------------------------------+
|  Usuari   |               | Usuari fictici amb el nom de la llista |
+-----------+               +----------------------------------------+

  Quan un usuari vol enviar MAIL a una llista (p. ex., CIUB o EXEC), el que
fa en realitat es enviar la seva nota (1) a un usuari fictici
(existeix pero no s'en fara LOGON mai), que nomes serveix per a
donar un nom a la llista (p. ex., per les llistes CIUB i EXEC els
usuaris son ZACUCIUB i ZACUEXEC -- mes avall parlare de com enviar coses).

  Normalment la nota la envia amb MAIL, pero tambe es pot enviar amb NOTE.
Si s'envia via MAIL i hi ha un MAILER, el MAILER la rep i la reenvia (2) al
reader de l'usuari fictici (Com que aquest usuari es fictici i mai
es fa LOGON, en principi el MAIL es quedaria alla fins que algu de fora
el purgues).

  Aqui es on interve LISTSERV: de tant en tant (cada 60 segons)
es 'desperta' i mira, per cada un deIs usuaris ficticis, si hi ha alguna
cosa al seu reader. Si hi troba algo, li pren al usuari fictici
(via el comando CP clase G TRANSFER) i ho procesa de la seguent manera:
el.limina alguns camps de la capcalera (com p.ex. CC:), cambia d'altres
a 'Comment:' (p. ex., 'Resent-To:') i genera, per cada un dels membres
de la llista (que LISTSERV coneix), una copia individualitzada del mail,
on el camp 'To:' nomes conte el nom de l'usuari concret dins de la
llista, evitant aixi les capcaleres llargues; a mes, afageix un camp
'Sender:' on indica qui es l'autor del MAIL, que s'ha enviat via LISTSERV,
i el 'userid' i el 'node' del LISTSERV.

  Finalment, LISTSERV envia aquests mails via MAILER (3), i llavors
el MAILER les re-envia als usuaris de la llista (4).

Significat de alguns deis camps que composen la capcalera de un MAIL
--------------------------------------------------------------------

  Haureu vist que a las capcaleres deis mails hi ha una serie de informacio,
molt mes complicada que la que surt amb NOTE. Aixo es perque NOTE es una
parideta de IBM que nomes serveix per instal.lacions IBM conectadas via RSCS
(o equivalent sota VAX o MVS), i en canvi tot aixo de MAIL, MAILER i L1STSERV
s'ajusta a la norma RFC822, que es un standard 'de facto' per al intercanvi
de mail, i serveix per a qualsevol ordinador i qualsevol xarxa.

  Podeu consultar el document definitori d'aquest standard, que esta
contingut al NETSERV i s'obte amb el comando NETS GET GATEWAY RFC822.

  Us explico de forma resumida i simplificada el significat d'alguns dels
camps.

From: es la identificacio de l'autor *logic* del mail (es a dir, de qui
      es el responsable de la nota. Noteu que la direccio electronica
      (de la forma userid@node) es tanca entre '<' i '>'.

Sender: es la identificacio de l'autor *fisic* de la nota (es a dir, qui
      ha enviat la nota, prescindint de qui la ha redactat). Si el
      Sender es igual al From, no es posa Sender

To:   es la identificacio del(s) receptor(s) de la nota.

cc:   es la identificacio de un o mes usuaris que rebran una 'copia
      complementaria' de la nota. P. ex., aquesta nota ha sigut enviada
      amb 'cc:' per Miguel Angel, encara que els demes no ho veureu, ja que,
      com he dit, LISTSERV el.limina els 'cc:'.

Received: son indicacions que deixan els diferents sistemes que processen
      el mail, com a informacio, i tambe per a poder determinar on s'han
      produit els problemes que hi puguin haber.

Date: es la fecha.

Comment: son comentaris [listserv posa com a comment els camps de direccio
      si envieu una NOTE (LONG)]

Resent-To:
Resent-From:
Resent-Date:
Resent-Sender:
 (etc)
      son camps que s'utilitzen si el mail ha sigut reenviat, per a
      poder distingir el que l'envia del que el re-envia. Pex, si l'usuari
      'A' (From: A) vol enviar un mail a l'usuari 'B' i
      s'equivoca i l'envia a l'usuari 'c' (To: C), i l'usuari C s'en
      adona de l'intencio de A, pot re-enviarlo a B (Aixo es fa automaticament
      des de MAIL amb la PF6, i es com us enviaba jo molts deis mails de
      l'altra gent). Llavors seria From: A To: C Resent-From: C Resent-To: B.

Passed-To:
Passed-From:
Passed-Date:
Passed-Sender:
 (etc)
      s'utilitzan per a substituir els tags 'Resent-' quan un mail
      re-enviat es torna a re-enviar. P. ex., si l'usuari 'c' del exemple
      anterior tambe la caga i ho envia a 'D', i 'D' s'en adona, i finalment
      ho envía a 'B', els tags 'Resent-' de 'c' passan a ser 'Passed-'.

Subject: indica el tema del mail. ES MOLT IMPORTANT INCLOURE UN TAG
      SUBJECT A TOTA LA CORRESPONDENCIA. El MAIL us pregunta el Subject
      cada cop que l'invoqueu, i tambe podeu donarlo al fer MAIL amb

        MAIL nickname (SUBJECT tema

      Quan una nota es en resposta a un altre, el Subject sol tenir la forma

        Re: tema original

      on 'Re:' indica que el mail es un mail en resposta a un altre mail.

Reply-To: indica que si es contesta la nota, s'ha de contestar a l'usuari
      especificat com a Reply-To i no al especificat com a From o Sender.
      P. ex., aquest MAIL posa Reply-To: <ZACUCIUB@EB0UB011> per tal que
      si algu diu alguna cosa o fa una pregunta, el mail arribi
      automaticament a tots els suscrits a la llista 'CIUB'.

In-Reply-To: indica, quan un mail es una resposta, de quin mail ho es.
      MAIL/MAILBOOK genera la data i l'hora del mail com a contingut
      de In-Reply-To, pero altres sistemes generan el userid i el node.
      Podeu veure un exemple de 'Reply' i 'In-Reply-To' fent PF5 sí esteu
      mirant aquest mail amb MAIL (no cal que despres envieu la nota:
      podreu sortir amb PF3 del modo reply).

La sintaxi d'aquests camps es:

Nom-de-tag: contingut

El nom-de-tag ha de comencar a la columna 1, i el contingut pot continuar
varias linias, sempre que es comenci mes enlla de la columna l.
AIguns contínguts son irrelevants semanticament (p. ex., 'Subject:') i
altres tenen que tenir algun valor obligatoriament (p. ex, 'To: ').
En els camps que s'han d'omplir, molt sovint la part obligatoria
va entre ,<, i '>' lila resta son comentaris; si els comentaris contenen
algun caracter semanticament significant (com, p. ex., el punt '.'),
s'ha de tancar la part del comentari que conte el caracter entre parentesis.
Aquesta es la rao de que el camp 'Sender:' d'aquesta nota posi

(ZCCBJBC@EB0UB011) Via List Processor <LISTSERV@EB0UB011>
L'adreca ZCCBJBC@EB0UB011 ha d'anar entre comentaris perque conte el caracter
'@', i perque sino seria (d'acord amb l'estandard RFC822) pres com el
'Sender:', que no soc jo.

Tota la part de capcalera ha de anar separada del texte per una linia blanca.

Finalment: canvis de protocols per les llistes 'CIUB' i 'EXEC'.
---------------------------------------------------------------

  Per a enviar informacio a alguna de aquestes llistes nomes cal que
envieu MAIL o NOTEs a ZACUCIUB (AT EB0UBOll pels de 4341) o ZACUEXEC,
respectivament. Tambe podeu utilitzar els exec MAILCIUB i MAILEXEC,
que es poden invicar tal qual, o com

  MAILCIUB tema de la nota

De totes formes, si utilitzeu MAIL o MAILCIUB us preguntara el nom de
ZACUCIUB; per a evitar que ho faci, pot anar be que definiu al vostre
NAMES un nickname qualsevol (encara que ELS QUE TENIEN CIUB I/O EXEC AL
SEU NAMES PODEN APROFITAR PER A CANVIAR-HO) amb userid ZACUCIUB (ZACUEXEC),
node EB0UBO11 i name qualsevol (ja que LISTSERV l'elimina), pero no buid.

  Josep Maria.

P.D. A veure si algu diu alguna cosa sobre lo deis EXECs.