Instal·lació i administració del servei de correu electrònic

ASCII

Acrònim amb el qual es coneix l’American Standard Code for Information Interchange, el codi de caràcters establert com a estàndard americà el 1963 i que va esdevenir de facto l’estàndard mundial.

En molts aspectes el correu electrònic imita el funcionament del correu postal. És un sistema distribuït que permet als usuaris enviar missatges a un destinatari final. El correu electrònic ha evolucionat molt dels primers sistemes que únicament permetien intercanviar missatges de text ASCII als correus electrònics amb continguts multimèdia d’avui en dia.

En el servei de correu es diferencia molt clarament entre el mecanisme de transport dels missatges i els missatges. El mecanisme de transport dels missatges és el protocol SMTP, i és independent del format i el contingut del missatge. Els missatges originals eren en text pla ASCII de 7 bits, però actualment en un missatge es permet tot tipus de contingut. Això és possible gràcies als tipus MIME, que descriuen i codifiquen els missatges.

El mateix disseny del sistema de correu ha evolucionat a mesura que ha avançat la tecnologia a internet. En el model bàsic de transport per SMTP s’exigeix que el receptor disposi de connexió permanent i que es connecti al servidor de correu localment per tal de consultar-lo. Quan els usuaris tenen accés a internet mitjançant un ISP (proveïdor de serveis d’internet) volen poder baixar tot el correu de cop i examinar-lo un cop tancada la connexió (per no pagar connexió telefònica). El protocol POP proporciona el mecanisme per descarregar del servidor de correu els missatges de l’usuari.

Amb la popularització d’internet s’abaixen els costos de connexió. L’usuari s’acostuma a baixar el correu des de llocs diferents, però usant el POP té l’inconvenient que el correu li queda repartit per diverses màquines. Cal un mecanisme que permeti accedir i gestionar el correu i les bústies directament en el servidor. El protocol IMAP ho fa possible.

Tot això ha canviat amb la popularització d’internet a tots els nivells i usant tota mena de dispositius. La major part del correu electrònic funciona actualment per web, gràcies a proveïdors webmail com els coneguts Gmail o Yahoo.

Protocols de correu electrònic

Per obtenir més informació sobre l’especificació del protocol SMTP en els RFC 821, 822, 2821 i 2822, aneu a la secció “Adreces d’interès” del web del mòdul.

Per conèixer més detalls de l’estàndard MIME, consulteu la secció “Els tipus MIME”.

El correu electrònic és un dels primers serveis que es va utilitzar a les xarxes i un dels més populars a internet. Ha evolucionat molt des dels primers sistemes, que podien intercanviar únicament missatges de text ASCII (7 bits), fins als portals web usats avui dia per milions d’usuaris per enviar-se continguts multimèdia.

El 1982 es van desenvolupar els estàndards que defineixen el correu electrònic. Es descriuen en els documents RFC 821, que explica el protocol de transmissió, i RFC 822, que descriu el format dels missatges. Aquests dos estàndards han evolucionat i actualment s’utilitzen els documents RFC 2821 i RFC 2822. A més, per permetre missatges multimèdia s’ha definit l’estàndard MIME en el document RFC 2231.

L’especificació original distingeix molt clarament entre el mecanisme de transport dels missatges i els missatges. El mecanisme de transport dels missatges és el protocol SMTP.

El protocol SMTP (Simple Mail Transport Protocol o protocol simple de transport de correu) és independent del format i el contingut del missatge. El missatge es compon del sobre (envelope) i el contingut, format per les capçaleres i el cos del missatge.

El correu electrònic és un sistema distribuït que permet als usuaris enviar missatges a un destinatari final. Hi intervenen diversos agents:

Ambigüitat dels agents

Els agents que intervenen en el sistema de correu electrònic fan sovint més d’un paper, fet que provoca ambigüitat en la seva definició.

Servidor SMTP

Sovint el programari de servidor SMTP (per exemple, Sendmail) fa tant la funció de client (emissor de missatges) com de servidor (receptor de missatges).

  • MUA (Mail User Agent o agent de correu d’usuari). L’usuari utilitza un MUA per redactar, rebre i manipular correus electrònics. Un MUA és un programari que permet aquestes capacitats, que poden ser aplicacions en línia d’ordres (per exemple, l’ordre mail d’Unix), aplicacions de text (per exemple, Mutt o Pine), interfícies gràfiques (com Thunderbird) i portals de correu web (com Gmail o Yahoo). L’usuari interactua usualment amb un MUA. En el cas d’enviar un correu, el MUA lliura el missatge al sistema de transport (SMTP) per fer-lo arribar al destinatari. En el cas de recepció de correu, el MUA obté el missatge d’una bústia de correu (on l’ha dipositat l’SMTP) i el mostra a l’usuari.
  • MTA (Mail Transport Agent o agent de transport de correu). L’agent de transport de correu és l’encarregat de transportar els missatges al destinatari indicat. Aquesta tasca la fa el protocol SMTP. L’MTA rep el missatge d’un MUA i s’encarrega del seu transport fins al destinatari final. Generalment realitzen la funció de client/servidor o emissor/receptor al mateix temps. La funció que es realitza en cada cas és:
    • MTA client SMTP (emissor). S’anomena client de correu o emissor (segons l’arquitectura client/servidor) el servidor SMTP (fixeu-vos en l’ambigüitat) que envia el correu al destinatari. És qui envia el correu utilitzant el protocol SMTP. Estableix les connexions amb els servidors/receptors SMTP.
    • MTA servidor SMTP (receptor). S’anomena servidor de correu o receptor el programari de servidor SMTP que rep els missatges de correu entrant i els lliura a la bústia del destinatari si es tracta d’un lliurament local, o els reenvia a un altre servidor SMTP si va destinat a un sistema remot. El fet que un receptor MTA rebi un correu no significa que el missatge hagi arribat al destinatari final.
  • MDA (Mail Delivery Agent o agent de lliurament de correu). Un altre element en l’estructura de correu és el MDA. És l’encarregat de fer el lliurament final del missatge a la bústia del destinatari. En el procés pot realitzar diverses accions segons un conjunt de regles .forward definibles per l’usuari. Un exemple d’MDA és el programa procmail, que permet filtrar els missatges entrants per posar-los en una bústia o una altra, esborrar-los, marcar-los com a correu brossa (spam), fer-ne còpies, reenviar-los a altres bústies i a altres destinataris… Usualment, en sistemes de correu que no disposen d’MDA és el mateix MTA el que diposita el missatge a la bústia del destinatari final.

@ (arrova)

Significa “at” en anglès o “a” en català. Usualment la composició d’una adreça de correu electrònic es descriu com a usuari@màquina (usuari tal a la màquina qual), però el nom del domini no correspon necessàriament al nom de la màquina. És més correcte dir usuari@domini.

Per exemple, pere@gmail.com indica el compte de correu d’en Pere en la màquina gmail.com. Però, de fet, no hi ha cap màquina que es digui així, sinó que és el compte de correu d’en Pere en el domini gmail.com. En realitat, Gmail té diverses màquines que responen a aquest nom de domini.

També hi ha altres conceptes que intervenen en el sistema de correu electrònic:

  • Adreça de correu. Els usuaris que volen utilitzar el sistema de correu electrònic han de disposar d’una bústia en un servidor de correu. Els missatges s’adrecen utilitzant la coneguda nomenclatura usuari@domini-servidor-correu, que es llegeix com a “compte de correu de l’usuari tal en el domini qual”. Així, per exemple, a un usuari amb un compte de correu de nom pere en el domini ioc.cat se li poden adreçar missatges a l’adreça pere@ioc.cat.
  • Bústia de correu o mailbox. Els usuaris tenen bústies en un servidor de correu. Quan el servidor de correu MTA rep un missatge destinat a un usuari amb compte de correu en el mateix servidor, el diposita a la bústia de correu corresponent (si no hi ha un MDA pel mig). Fixeu-vos que dipositar el missatge en la bústia de l’usuari no garanteix que l’usuari el llegeixi. Cal un altre pas, que és la recuperació del missatge de la bústia per part de l’usuari. Aquest pas es realitza des d’un MUA i sovint empra protocols com POP o IMAP, fora de l’abast de les explicacions del correu SMTP.
  • Llista de correu i àlies. Els àlies i les llistes de correu es tradueixen en adreces de comptes de correu. Si la llista de correu es gestiona localment, el MUA local l’expandirà en el conjunt d’adreces d’usuari corresponents i enviarà el correu electrònic a cada una. Si la llista d’usuaris és remota, s’envia el correu electrònic al sistema remot i serà l’MTA remot el que l’expandirà i enviarà un correu electrònic a cada membre de la llista. Fixeu-vos que si la llista conté usuaris d’altres dominis de correu (on sigui del món), farà arribar una còpia a aquests usuaris.

El model funcional del protocol SMTP, que mostra els elements que intervenen en una comunicació d’aquest tipus, es pot veure a figura.

Figura Model funcional del protocol SMTP

Exemple de funcionament del correu electrònic

El correu web té un funcionament similar al correu electrònic.

Per exemple, un usuari de Gmail utilitza com a MUA el web de Gmail per enviar un missatge a un usuari de Yahoo. Gmail transfereix el missatge per SMTP al servidor de correu de Yahoo i el missatge es diposita a la bústia del destinatari. Aquest, quan li sembla, consulta el correu utilitzant el lloc web de Yahoo com a MUA.

Exemples de programes que implementen SMTP: Sendmail, Exim, Postfix, MS Exchange Server.

Per tant, vist en conjunt, un MUA (Thunderbird, per exemple) permet a l’usuari crear un correu electrònic i lliurar-lo a l’MTA del sistema (per exemple, Sendmail) perquè el faci arribar al destinatari final. Usant el protocol SMTP, l’MTA s’encarrega de fer el lliurament al sistema final (pot ser amb una connexió directa o encaminant-se a través de diversos MTA) i el missatge es diposita en la bústia de correu del receptor. En aquest procés de deixar el missatge en la bústia del receptor hi pot haver un MDA que “postprocessi” el missatge o ho pot fer l’MTA directament. Quan ho considera oportú, el receptor recupera els missatges de la bústia utilitzant un MUA i un mecanisme d’accés adequat (per exemple, amb Thunderbird, usant el protocol POP o IMAP).

Format dels missatges

El protocol SMTP s’encarrega del transport de missatges de correu amb independència del format i del contingut. Els missatges es componen de diferents elements que es descriuen en l’especificació SMTP (corresponent al document RFC 821) i en l’especificació pròpia dels missatges d’internet (document RFC 822).

El missatge es desglossa en els elements següents:

Els camps FROM i RCPT del sobre no porten dos punts (:) mentre que les capçaleres From i To del contingut sí que en porten.

Alguns exemples de capçaleres: From:, To:, Date:, Subject:

  • Sobre o envelope. Com passa en el correu postal, per fer arribar un missatge cal un sobre en el qual s’indiquin el destinatari i el remitent. L’especificació de l’SMTP (document RFC 821) descriu com a sobre el conjunt de dades necessàries per al transport del missatge (emissor, receptor, prioritat, nivell de seguretat…). Generalment, el sobre consta tan sols dels camps FROM (emissor) i RCPT (receptor). L’MTA utilitza el sobre per encaminar el missatge. De fet, la separació entre sobre i contingut és confusa i l’MTA obté les dades del sobre a partir de les capçaleres del contingut.
  • Contingut. El contingut d’un missatge és el que està descrit en el document RFC 822 Standard for ARPA Internet Text Messages (estàndard per als missatges de text d’internet). Tot contingut consta d’un conjunt de capçaleres (headers), una línia en blanc i un cos (body) del missatge:
    • Capçaleres (headers). El missatge conté capçaleres del tipus clau: valor, cada una en una línia independent.
    • Línia en blanc. Les capçaleres se separen del cos del missatge amb una línia en blanc.
    • Cos del missatge. El cos del missatge conté el missatge que es vol fer arribar al receptor. L’especificació inicial només permet text ASCII de 7 bits (sense símbols internacionals). El cos del missatge acaba amb una línia que conté a l’inici únicament un punt.

Les capçaleres descrites en l’especificació inicial tenen com a objectiu descriure clarament l’emissor i el receptor o receptors del missatge i la data, i permetre identificar el missatge (ID únic), entre d’altres.

En l’exemple següent podeu veure els elements que formen el contingut i les capçaleres usuals d’un correu electrònic:

Received: by 10.100.195.12 with HTTP; Sun, 11 May 2008 10:11:38 -0700 (PDT)
Message-ID: <7b4e8fcc0805111011g83da6b0rbdb4f63409024720@mail.gmail.com>
Date: Sun, 11 May 2008 19:11:38 +0200
From: "Pere Puig" <puig@correu.fp-oberta.org>
To: ppuig@correu.fp-oberta.org
Subject: =?ISO-8859-1?Q?Exemple_de_missatge_de_correu_amb_capçaleres
Delivered-To:ppuig@correu.fp-oberta.org

Hola,
Això és un exemple de missatge de correu.
Conté les capçaleres usuals.
S'ha generat des del web de Gmail i s'envia també a Gmail.

Pere

Aquestes són algunes de les capçaleres estàndard:

  • From: indica l’adreça de correu de l’emissor del missatge.
  • Sender: indica l’adreça de qui ha enviat el missatge. No s’utilitza si qui ha enviat el missatge és l’emissor del missatge. Serveix per diferenciar entre qui envia el missatge físicament i en nom de qui ho fa.
  • To i Cc: serveixen per indicar els destinataris del missatge. La idea original era posar un destinatari en el To i la resta en el Cc, però amb la utilització dels MUA actuals i la utilització de llistes d’usuaris generalment es posen tots els destinataris en el To.
  • Bcc: prové de l’anglès blind carbon copy o còpia oculta. S’indiquen els destinataris que han de rebre el missatge però que no han d’aparèixer a la llista de destinataris. Serveix per evitar que els altres destinataris sàpiguen qui n’ha rebut una còpia.
  • Reply-to: indica l’adreça de retorn del missatge al remitent. L’emissor pot voler que si el missatge es retorna o es respon, l’adreça a la qual es dirigeix la resposta sigui diferent de la indicada en el camp From. És útil per concentrar les respostes en un compte de correu quan l’emissor en té més d’un.
  • Received: cada MTA que processa un missatge afegeix una entrada de tipus Received en el missatge. És una manera de realitzar el seguiment o la traçabilitat dels MTA pels quals ha passat el missatge. La informació afegida descriu l’emissor (From) i el receptor (By), el mecanisme físic (Via), l’identificador del missatge (ID) i la data i hora (Date).
  • Date: indica la data i hora en què s’ha generat el missatge. L’hi afegeix el primer MTA que rep el missatge del MUA.
  • Message-ID: és l’identificador únic del missatge. Cada missatge s’ha de poder referenciar de manera única a tot el món. Això permet que les respostes indiquin a quin missatge es refereixen. S’utilitzen els noms de domini i un identificador numèric únic que genera l’MTA que rep el missatge per enviar.
  • Subject: descriu el propòsit del missatge o assumpte. És un petit text explicatiu.
  • In-reply-to: quan un missatge és una resposta a un missatge anterior, aquest camp indica a quin missatge original fa referència.
  • Keywords: és la llista separada per comes de paraules clau descriptives del missatge.
  • Comments: és el text de comentari del missatge que no interfereix en el contingut.
  • References: quan un missatge fa referència a altres missatges anteriors, es pot indicar mitjançant aquesta capçalera.
  • Encrypted: indica el tipus d’encriptació que s’ha utilitzat per al missatge. L’especificació del format dels missatges de correu (descrita en el document RFC 822) no indica cap tipus d’encriptació, simplement reserva una capçalera per indicar-ne el tipus.
  • Return-path: identifica el camí de retorn cap a l’origen. Aquesta informació l’ha de posar l’MTA receptor. Actualment està en desús, de manera que normalment conté l’adreça de l’emissor.
  • X-<userDefined>: els usuaris poden crear les pròpies capçaleres amb el nom que vulguin però començant per X-. D’aquesta manera s’assegura que si apareixen noves capçaleres oficials en el futur, no xocaran amb capçaleres definides pels usuaris.

Bústies de correu

Les bústies de correu són el sistema que permet l’emmagatzematge dels correus electrònics. Estan ubicades en l’espai de disc del servidor que allotja el servei de correu electrònic. Els dos principals formats són el mbox i el Maildir.

El format tradicional d’UNIX per a les bústies de correu és l’mbox. Les bústies dels usuaris s’emmagatzemen normalment a la carpeta /var/mail o /var/spool/mail (a vegades una és un enllaç simbòlic de l’altra). En aquesta carpeta hi ha un sol fitxer per usuari que conté tots els seus correus, concatenats un darrere l’altre. Aquest fet fa que sigui molt ràpid fer una cerca en la correspondència d’un usuari, tot i que aquest sistema no és gens escalable. Un dels grans problemes són els bloquejos, ja que per afegir un nou correu cal bloquejar el fitxer i això el fa inaccessible per a la cerca. El RFC 4155 dona informació sobre aquest tipus de bústia, però en cap cas es tracta d’unes especificacions.

La principal innovació del format Maildir és que té un fitxer per a cada correu i estan estructurats en carpetes, i això fa que no es produeixin bloquejos (només a nivell d’un sol correu). Els tres principals directoris són:

  • new: és la carpeta on van a parar els correus nous. Un cop llegits passen a la carpeta cur.
  • cur: és on es troben els correus que ja no són nous.
  • tmp: és una carpeta temporal que, entre d’altres coses, serveix per rebre correctament els missatges abans de ser moguts a la carpeta new.

Aquest sistema és més estable, ràpid i escalable que el tradicional mbox. I el problemes de corrupció de fitxer afecten notablement menys a aquest sistema ja que tots els correus estan separats.

No obstant, també hi ha altres formats de bústia, més minoritaris. Aquests són:

  • dbox: format de bústia d’alt rendiment per a Dovecot. Té dues variants:
    • sdbox (single dbox): semblant al Maildir, un missatge per correu.
    • mdbox (multidbox): múltiples correus per fitxers, però no a l’estil de mbox.
  • mbx/mix: format de bústia del programari UW-IMAP de la Universitat de Washington. L’anterior format era el mbx, que s’ha substituït pel mix, que permet un millor rendiment.
  • Mailstore: format de bústia originari del programari Exim. Consta de dos fitxers per correu amb les extensions .env i .msg, un per al sobre (envelope) i l’altre per al missatge.
  • Pst (Personal Storage Table): format obert propietari de Microsoft. És utilitzat per Microsoft Exchange Server i Microsoft Outlook.

Funcionament de l'SMTP

'Push'

Es diu que l’SMTP és un protocol que fa push (lliura), però no pull (agafa). Els usuaris finals han d’usar altres mecanismes per accedir remotament als seus comptes de correu.

El funcionament del protocol SMTP imita el correu postal en molts aspectes. L’SMTP és un protocol d’emmagatzemament i enviament que funciona igual que es fa amb les cartes de correu, que es lliuren en una oficina postal, d’allà a una altra, i així successivament fins arribar al destinatari final. De fet, les cartes es lliuren a la bústia del destinatari final i aquest les ha de recollir.

El servidor SMTP és una aplicació distribuïda que permet enviar missatges electrònics. Utilitza el protocol de transport TCP i el port 25.

MX

En la base de dades d’un servidor DNS, els equips que fan de servidors de correu d’un domini s’identifiquen per les entrades tipus MX. Si un domini no disposa d’entrades MX, s’utilitza l’amfitrió que defineix el domini.

En l’esquema original en què es va desenvolupar l’SMTP, una organització disposa d’un servidor SMTP (un MTA) que rep correu electrònic de fora de l’organització i el diposita en les bústies de correu locals del servidor. També recull el correu intern de l’organització i l’envia fora.

Cada organització disposa d’una o més màquines encarregades de gestionar el correu. Així, quan s’envia un correu electrònic a l’usuari pere@ioc.cat, cal que l’organització o domini ioc.cat disposi de màquines que fan la funció de servidors de correu. ¿Com trobarà l’SMTP a quin servidor de correu ha de lliurar els correus electrònics destinats a un domini? Utilitzant el protocol DNS (domain name system, sistema de noms de domini) i fent una consulta de tipus MX obtindrà la màquina o màquines que fan la funció de servidors de correu del domini consultat.

El client SMTP o emissor estableix una connexió TCP amb el port 25 del servidor SMTP o receptor. En una mateixa connexió l’emissor pot enviar un o més missatges al receptor. Si el mateix missatge va destinat a diversos receptors del sistema final, el missatge s’envia un sol cop i l’MTA receptor el replica a cada destinatari.

El client SMTP o emissor disposa d’una cua de missatges per enviar i una llista de destinataris per a cada missatge. Els destinataris poden ser en destinacions diferents (evidentment) i, per tant, li caldrà connectar-se als diferents servidors de destinació per fer-los arribar els missatges.

Llistes negres de servidors de correu

Els servidors de correu que accepten correus electrònics de tots els clients a totes les destinacions són inclosos en llistes negres perquè poden ser generadors de correu brossa.

Quan un destinatari no és accessible, el missatge es pot tornar a posar a la cua de missatges pendents d’enviar o es pot descartar (segurament després de diversos intents infructuosos) tot notificant-ne l’emissor.

Correu brossa o 'spam'

Correu brossa, correu no desitjat o no sol·licitat. És un correu que es rep insistentment i que bombardeja les bústies dels usuaris de manera mecànica.

Avui en dia el servidor de correu pot ser a qualsevol lloc del món i no cal que cada organització en tingui un. Es pot utilitzar el del proveïdor ISP o el de qualsevol servei extern de correu (per exemple, Google permet externalitzar el correu a empreses tot mantenint el domini propi de l’empresa). Això significa que el servidor SMTP ha de verificar si accepta o no peticions d’enviar correu d’un client. Es pot verificar el client mitjançant l’adreça IP o mitjançant altres mecanismes d’autenticació i seguretat. Evidentment, disposar d’un servidor SMTP que accepta peticions de clients sense verificar qui són és una porta oberta a permetre correu brossa. Normalment els servidors SMTP restringeixen qui pot fer ús del servei (quins clients) i a quines destinacions.

Un cop un servidor SMTP accepta un correu electrònic per fer-ne el lliurament (d’un MUA com Thunderbird, per exemple) tot validant que accepta rebre correus electrònics d’aquest client, estableix una connexió TCP al port 25 del servidor SMTP destinatari (ha obtingut l’adreça IP fent la resolució DNS de la part del domini de l’adreça de correu).

Ordres/respostes SMTP

S’entén per CRLF una línia en blanc. Ve de l’anglès Carriage Return - Line Feed (retorn de carro - salt de línia).

L’emissor sempre porta el control de la comunicació i inicia la connexió amb el receptor. El diàleg consisteix en un intercanvi d’ordres i respostes que segueixen les especificacions de Telnet:

  • Ordres. Són codis de quatre caràcters (HELO, MAIL, DATA…) i arguments opcionals separats per espais i acabats amb <CRLF>. Per a cada ordre es rep una resposta del receptor.
  • Respostes. Són codis numèrics de tres dígits, un espai i un missatge descriptiu que pot variar segons la implementació.

Un diàleg bàsic entre emissor i receptor SMTP podria ser el següent:

  • HELO <domini> / EHLO <domini>. Un cop connectat, l’emissor s’ha d’identificar amb l’ordre HELO i indicar el domini al qual es connecta. Actualment, els servidors SMTP utilitzen extensions i l’ordre preferida per identificar-se és EHLO (significa extended HELO).
  • MAIL FROM: <emissor>. Identifica l’emissor del missatge i genera la capçalera From del missatge. El receptor comprova que l’emissor sigui un usuari vàlid, és a dir, que accepti missatges d’aquest origen. Si no el pot validar, envia una resposta denegant-li la comunicació. Els equips amb el relay configurat per permetre enviar missatges de tothom són els principals generadors de correu brossa.
  • RCPT TO: <destinatari>. Indica el destinatari del missatge. Aquesta ordre es pot repetir tantes vegades com destinataris tingui el missatge. També cal que el receptor accepti el destinatari, que pot ser un destinatari local, o que accepti fer el reenviament si és un destinatari remot. Aquesta ordre genera la capçalera To en el missatge.
  • DATA. Indica que a continuació s’enviarà el missatge. Tot el que es transmet a continuació és el contingut del missatge, que finalitzarà en trobar una línia que només inclou un punt (.<CRLF>). El contingut segueix les especificacions del document RFC 822; per tant, pot contenir capçaleres a l’inici, una línia en blanc a manera de separador i el cos. No es pot enviar un missatge (l’ordre DATA) fins que el receptor no ha confirmat que accepta almenys un destinatari. Això evita transmetre missatges que es descartarien en la destinació.
  • QUIT. L’emissor envia l’ordre per indicar al receptor que vol finalitzar la comunicació. El receptor confirma la recepció i llavors tots dos poden finalitzar la transmissió.

En la secció “Annexos” del web d’aquest mòdul teniu captures dels diferents diàlegs SMTP, POP i IMAP.

En l’exemple següent podeu veure un diàleg client/servidor SMTP mitjançant ordres i respostes Telnet:

[root@host ~]# telnet www.escola.org 25 
Trying 22.170.21.168... 
Connected to www.escola.org. 
Escape character is ‚^]'. 
220 escola.org ESMTP Sendmail 8.13.8/8.13.8; Sat, 26 Apr 2008 
19:56:05 +0200 
EHLO escola.org 
250-escola.org Hello 106.Red-71-92-14.dynamicIP.rima-tde.net 
71.92.14.106], pleased to meet you 
250-ENHANCEDSTATUSCODES 
250-PIPELINING 
250-8BITMIME 
250-SIZE 10000000 
250-DSN 
250-ETRN 
250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN 
250-DELIVERBY 
250 HELP 

MAIL FROM: pere@xtec.cat 
250 2.1.0 pere@xtec.cat... Sender ok 
RCPT TO: pere@correu.escola.org 
250 2.1.5 pere@correu.escola.org... Recipient ok

DATA 
354 Enter mail, end with "." on a line by itself 
Hola, 
Aquest és un missatge de prova per enviar un 
correu usant Telnet al servidor SMTP de l'escola. 
S'envia una còpia a dos usuaris locals al servidor. 
S'ha denegat fer relaying i enviar una còpia a 
l'exterior.
Pere 
. 
250 2.0.0 m3QHu5B3012660 Message accepted for delivery 

QUIT
221 2.0.0 escola.org closing connection 
Connection closed by foreign host.

Ordres SMTP

Per obtenir la llista d’ordres del protocol podeu consultar el document RFC 2821. Atès que és un servidor concret, podeu consultar les ordres que implementa amb l’ordre HELP.

Amb els camps MAIL FROM i RCPT TO, el protocol SMTP obté les dades necessàries per generar el sobre o envelope.

A part de les ordres bàsiques mostrades anteriorment, hi ha altres ordres en el protocol SMTP, com ara les següents:

  • RSET. L’emissor pot interrompre l’enviament de missatges.
  • NOOP. Aquesta ordre no fa res (‘no operate’), però força el receptor a enviar una resposta afirmativa. Serveix per confirmar que la connexió encara és oberta.
  • HELP. Fa una llista de les ordres que implementa el servidor. Els servidors SMTP no implementen necessàriament totes les ordres descrites pel protocol.
  • VRFY <destinatari>. L’emissor pot verificar l’existència del destinatari.
  • EXPN <destinatari>. Permet a l’emissor verificar l’existència d’una llista de correu i obtenir-ne els noms dels membres.
  • SEND, SOML, SAML. Permeten enviar els missatges tant a les bústies de correu com als terminals.
  • TURN. Permet intercanviar els papers entre emissor i receptor. El receptor hi ha d’estar d’acord.

Els servidors SMTP no implementen necessàriament totes les ordres, però hi ha un conjunt d’ordres mínim definit pel protocol que tot servidor SMTP ha d’implementar.

El conjunt d’ordres mínim que tot servidor SMTP ha d’implementar és el següent:

HELO <domini>

MAIL FROM: <emissor>

RCPT TO: <destinatari>

DATA

RSET

NOOP QUIT

El protocol SMTP permet treballar amb missatges ASCII de 8 bits i amb extensions del protocol, és a dir, afegir als servidors SMTP funcionalitats extres segons el programari de servidor utilitzat. El client pot sol·licitar al receptor la llista de les extensions que implementa i fer-li saber que les vol utilitzar. El mecanisme consisteix a fer que el client enviï un EHLO en lloc del HELO estàndard. Si el receptor implementa extensions, respondrà afirmativament i en farà una llista; si no les implementa, respondrà negativament. Llavors l’emissor pot fer un HELO estàndard.

Les respostes es poden classificar en quatre grans grups. El primer dígit del codi numèric de tres dígits de la resposta indica el grup al qual pertany:

  • Positiva (2xx). L’acció que ha sol·licitat l’emissor és acceptada pel receptor. L’emissor pot fer una nova sol·licitud. Les respostes d’aquest grup comencen totes pel dígit 2. En els llistats de codi es pot observar que, per exemple, el valor 250 correspon a OK o acció realitzada correctament.
  • Intermèdia positiva (3xx). L’acció sol·licitada s’ha acceptat, però està suspesa pendent de rebre informació addicional que l’emissor haurà de proporcionar.
  • Negativa transitòria (4xx). La sol·licitud no s’ha acceptat i l’acció no s’ha realitzat, però es tracta d’un error temporal i es pot tornar a intentar més tard. L’emissor pot tornar a fer la sol·licitud més endavant.
  • Negativa pertinent (5xx). L’ordre no s’ha realitzat i, per tant, la sol·licitud no ha estat acceptada.

MIME

Els missatges de correu tenen el format definit en l’RFC 822 (actualment, RFC 2822), que únicament permet missatges de text net ASCII de 7 bits. No es permeten els caràcters accentuats, caràcters internacionals (ASCII de 8 bits) i molt menys la transferència de dades binàries com imatges, àudio, aplicacions, PDF o altres. Però tot això i molt més s’envia avui en dia per correu electrònic.

El juny del 1992 es va definir el que es coneix com a MIME (Multipurpose Internet Mail Extension o extensió de correu d’internet per a ús múltiple) en l’RFC 1341, que actualment ha evolucionat en els RFC 2045 i RFC 2049. El MIME utilitza missatges RFC 822, però afegint una estructura al cos del missatge i regles de codificació per a missatges no ASCII. El gran avantatge del MIME és que permet seguir utilitzant les mateixes eines de l’SMTP que fins ara i només cal modificar els MUA perquè apliquin MIME. A l’MTA, el cos del missatge li és absolutament indiferent (per tant, pot estar codificat), ja que només utilitza el sobre per enviar el missatge i el contingut s’envia com un tot.

El MIME es basa en tres elements per permetre qualsevol tipus de contingut en un missatge de correu:

  • Capçaleres MIME. Es creen cinc noves capçaleres de correu per definir informació del cos del missatge. No totes són obligatòries.
  • Formats de contingut. Es defineixen diferents formats de contingut que permeten als MUA receptors interpretar el contingut de manera adequada i saber si reben un full de càlcul, un vídeo…
  • Esquemes de codificació de transferència. Es realitza una transformació de les dades a un format manipulable per al transport SMTP (que només permet caràcters ASCII de 7 bits).

Podeu veure els components d’un missatge amb contingut MIME en l’exemple següent:

From root@tftp.server.cat  Fri Jun 13 17:26:31 2012 
Return-Path: <root@tftp.server.cat> 
Received: from tftp.server.cat (localhost [127.0.0.1]) 
 by tftp.server.cat (8.14.1/8.14.1) with ESMTP id m5DFQTH7003922 
 for <pere@tftp.server.cat>; Fri, 13 Jun 2012 17:26:30 +0200 
Received: (from root@localhost) 
  by tftp.server.cat (8.14.1/8.14.1/Submit) id m5DFQSIq003918 
  for pere@tftp.server.cat; Fri, 13 Jun 2012 17:26:28 +0200 
Date: Fri, 13 Jun 2012 17:26:27 +0200 
From: root <root@tftp.server.cat> 
To: pere@tftp.server.cat 
Subject: missatge amb atchment 
Message-ID: <20080613152627.GA3909@portatil.local.lan> 
MIME-Version: 1.0 
Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" 
Content-Disposition: inline 
User-Agent: Mutt/1.5.17 (2007-11-01) 
Status: O 

--zYM0uCDKw75PZbzx 
Content-Type: text/plain; charset=us-ascii 
Content-Disposition: inline 

missatge de root a l'usuari pere 
conté adjunt un pdf i jpeg 
adéu! 

--zYM0uCDKw75PZbzx 
Content-Type: application/pdf 
Content-Disposition: attachment; 
filename="informatica_AX_ud2.pdf" 
Content-Transfer-Encoding: base64 
... output suprimit (contingut del pdf codificat en base64) ...
--zYM0uCDKw75PZbzx 
Content-Type: image/jpeg 
Content-Disposition: attachment; filename="cd15_11_puerto-
madrin.jpg" 
Content-Transfer-Encoding: base64 
... output suprimit (contingut del jpeg codificat en base64) ...
--zYM0uCDKw75PZbzx--

Capçaleres MIME

Les cinc capçaleres que defineix l’especificació MIME aporten informació del contingut del missatge.

Aquestes capçaleres són les següents:

  • MIME-version. Identifica el tipus MIME del missatge. Si indica 1.0, es tracta d’un missatge MIME; si no, es tracta d’un missatge ASCII.
  • Content-description. És un text que descriu el tipus de contingut. No és obligatori i no té cap funcionalitat més enllà de la merament descriptiva.
  • Content-ID. Identifica el contingut de manera única, igual que ho fa el camp Message-ID.
  • Content-transfer-encoding. És el mecanisme de codificació utilitzat en el missatge per poder-lo transmetre. El contingut que no és ASCII de 7 bits es codifica per poder ser transmès.
  • Content-type. Descriu el tipus de contingut segons la taula de tipus MIME. Això permet a un MUA obrir l’aplicació pertinent per gestionar el contingut. Si, per exemple, el tipus és image/jpeg, permet al MUA saber que en pot manipular el contingut amb una aplicació de gestió d’imatges.

Tipus MIME

Es defineix un conjunt de tipus i subtipus MIME amb un esquema tipus/subtipus. Originàriament es van definir els set tipus que es descriuen a continuació, però en l’actualitat n’hi ha molts més.

  • text/native. Text net en format ASCII de 7 bits.
  • multipart/<subtipus>. El missatge conté múltiples parts independents. Un delimitador (o boundary) indica la separació de cada part. El delimitador és únic i no apareix en el cos de les parts. El delimitador es troba a l’inici i al final de cada part i comença amb dos guions. L’última part acaba amb un delimitador que comença i acaba amb dos guions. Cada part pot ser qualsevol cosa!
  • multipart/parallel. Múltiples parts, en ordre. És a dir, les parts s’han de mostrar en el receptor en l’ordre indicat.
  • multipart/mixed. Múltiples parts. No es defineix cap ordre.
  • multipart/alternative. Les parts són versions alternatives del mateix contingut en ordre creixent de fidelitat. El receptor escull la més apropiada. Per exemple, un text s’envia com a text pla en una primera part i com a PDF en una segona; si el receptor no disposa de PDF podrà usar la part en text net.
  • multipart/digest. Cada part és un missatge de correu individual. S’utilitza quan un correu electrònic conté diversos correus electrònics en el seu interior (per exemple, reenviaments).
  • message/rfc822. El cos és un missatge de correu complet, amb capçaleres i cos. Pot ser un missatge MIME tot i que al nom hi digui “rfc822”.
  • message/partial. Permet fragmentar un missatge llarg en diferents missatges. Cada fragment ha de disposar d’un identificador, número de fragment i nombre total de fragments.
  • message/external body. Les dades del cos del missatge no estan en el missatge sinó que cal baixar-les a part. En la capçalera Content-type es descriu el tipus de contingut i el tipus d’accés, que pot ser FTP, TFTP, anon-FTP (FTP anònim), local-file, AFI i mail-server. Per exemple, el contingut pot ser una imatge no inclosa en el missatge sinó que calgui baixar d’un servidor FTP.
  • image/jpeg. Imatge codificada JPEG
  • image/gif. Imatge GIF
  • video/mpeg. Vídeo en format MPEG (Moving Picture Experts Group, grup d’experts d’imatges en moviment)
  • audio/basic. Àudio en format estàndard
  • application/postscript. Dades binàries en format PostScript. Per exemple, PDF.
  • application/octet-stream. Dades binàries

Codificació de transferència

Les dades binàries i els caràcters internacionals (que no pertanyen al conjunt ASCII de 7 bits) no es poden enviar per correu electrònic. Per poder-ho fer, cal codificar-los en un altre format.

L’especificació MIME defineix els tipus de codificacions següents:

Base64

Per aprendre el funcionament de Base64 podeu consultar la Viquipèdia:

en.wikipedia.org/wiki/Base64

  • 7bit. Indica que les dades es transfereixen en ASCII de 7 bits. No es realitza cap codificació.
  • 8bit. No es realitza cap codificació i les dades es transmeten en ASCII de 8 bits. Evidentment, cal que receptor i emissor permetin la transferència a 8 bits (una extensió d’SMTP).
  • Binary. Es transmeten les dades en binari tal com són, sense cap codificació ni control de la longitud de les línies. Si s’envien dades en binari (en cru), no es garanteix que la transmissió sigui correcta.
  • X-token. Indica la utilització d’un esquema de codificació de transport no estàndard, un esquema propi. Emissor i receptor han de compartir aquest esquema de codificació.
  • Quoted-printable. Quan la majoria de caràcters del missatge són imprimibles excepte una petita part, és més eficient utilitzar aquesta codificació que Base64. Aquest esquema codifica els caràcters no imprimibles amb un signe igual (=) i el codi hexadecimal del caràcter. Es garanteix que les línies tenen una longitud no superior a 36 caràcters mitjançant salts de línia reversibles.
  • Base64. És l’esquema de codificació més usat per a la transferència d’informació binària. Converteix l’entrada en un conjunt de caràcters imprimibles i, per tant, immunes al transport per SMTP. Consta d’un conjunt de 63 caràcters imprimibles i un més de farciment (2 ^ 6 = 64 caràcters). Cada 24 bits de l’entrada binària (3 bytes) es codifica en quatre blocs de 6 bits (4 * 6 = 24 bits). A cada bloc de 6 bits li correspon un caràcter imprimible que es posa en 1 byte. Per tant, per cada 24 bits d’entrada binària, s’utilitzen 32 bits de transmissió (4 * 1 byte).

Exemple de codificació en Base64

Aquest és un petit exemple extret de la Viquipèdia on s’observa que el text “Man” original (3 bytes = 24 bits) acaba codificat en Base64 com a “TWFu” (4 bytes).

Text content M a n
ASCII 77 97 110
Bit pattern 01001101 01100001 01101110 (8 bits * byte)
Bit pattern 010011 010110 000101 101110 (divisió en blocs de 6 bits)
Index 19 22 5 46
Base64-encoded T W F u

Instal·lació d'un servidor

Per obtenir més informació sobre els servidors de correu actuals, consulteu l’activitat titulada: Quota de mercat dels servidors de correu.

Hi ha diverses aplicacions de servidor de correu en el mercat i moltíssims clients de correu de tota mena, tant en versió gràfica com d’entorn de text. Algunes d’aquestes aplicacions són de font pública i es poden baixar gratuïtament d’internet.

Sendmail

Per conèixer els orígens i l’evolució de Sendmail us recomanem consultar l’article sobre el servei a la Viquipèdia:

en.wikipedia.org/wiki/Sendmail

La majoria de sistemes GNU/Linux proporcionen l’aplicació client Mail i sovint també Mutt, que és una versió de Mail amb pantalles en mode text. Els sistemes GNU/Linux i Unix també disposen d’una aplicació servidor omnipresent anomenada Sendmail.

Quan es parla d’instal·lar el servei de correu es fa referència al procés d’instal·lació i configuració del programari del servidor. Això es fa de manera molt similar a la d’altres serveis de xarxa (com els serveis DHCP, DNS, HTTP o FTP): es tracta d’instal·lar els paquets o tarballs de l’aplicació servidor i fer-ne la configuració apropiada.

Per fer això cal plantejar-se els passos i reflexions següents:

  • Preguntar-se i buscar l’aplicació més adient: Quin programari proporciona aquest servei? Quines característiques té? Com es pot adquirir?
  • Observar l’estat de la xarxa actual: El servei ja està en funcionament? Existeix ja un servidor de correu instal·lat i actiu?
  • Obtenir l’aplicació que proporciona el servei de correu.
  • Instal·lar l’aplicació servidor.
  • Comprovar que la instal·lació s’ha fet correctament.
  • Configurar el servei en el servidor i comprovar que els clients hi poden accedir.
  • Comprovar que el servei funciona correctament.

L’eina utilitzada en aquest mòdul per estudiar els serveis de servidor de correu és Sendmail. Podeu trobar tota la informació sobre aquest servidor a www.sendmail.org.

Usualment, l’administrador acaba utilitzant l’aplicació servidor que li proporciona el seu sistema operatiu. Si utilitzeu Windows, l’empresa Microsoft disposa d’una aplicació pròpia, però en podeu trobar d’altres a internet. Igualment, si utilitzeu GNU/Linux, segurament la mateixa distribució proporciona un servidor de correu o bé n’existeix algun de clàssic provinent d’Unix. De totes maneres, en podeu obtenir d’altres a internet.

Instal·lació de l'aplicació servidor

Els usuaris de GNU/Linux poden buscar fàcilment per internet paquets de servidor de correu Sendmail usant eines com yum o apt-get i els repositoris de paquets apropiats segons la distribució que utilitzin. A més, sempre es pot recórrer a Google per localitzar tot allò que faci falta.

Un cop instal·lat el programari, cal identificar què s’ha instal·lat, els paquets i el contingut. A vegades no s’instal·len paquets sinó fitxers tarball, el contingut dels quals també cal saber examinar. És important identificar els components instal·lats que corresponen a fitxers executables, els que corresponen a fitxers de configuració i els que corresponen a fitxers de documentació.

Tot servei instal·lat s’ha de configurar apropiadament i s’ha posar en marxa. Per tant, cal saber gestionar l’estat del servei (engegar, aturar, recarregar…) i definir l’estat que ha de tenir en els diferents runlevels del sistema.

En definitiva, el procediment d’instal·lació inclou usualment:

  • Buscar el programari del servei (sigui en format de paquets .deb, .rpm o .tar) i descarregar-lo amb l’eina apropiada segons la distribució que s’utilitzi.
  • Examinar el sistema per identificar el programari, els paquets, instal·lat relacionats amb el servei.
  • Identificar els components del servei: fitxers executables, fitxers de configuració i fitxers de documentació.
  • Consultar i establir l’estat del servei (engegar i aturar) i saber establir l’estat per defecte per a cada runlevel.

Verificació de l'accés als comptes de correu

Un servidor de correu realitza la funcionalitat de client i de servidor SMTP. Com a client s’encarrega d’enviar els missatges que hi ha a la cua de missatges al servidor apropiat. És a dir, si un missatge està dirigit a un usuari del domini gmail.com, s’encarrega de fer arribar el missatge a algun dels servidors de correu d’aquest domini.

Com a servidor SMTP té la funció d’escoltar les peticions entrants que li fan els clients SMTP i atendre-les. Això significa “rebre” els missatges i fer els passos necessaris per fer-los arribar a la bústia del client. Si el sistema de correu no utilitza un MDA propi (ho són programes com procmail o SpamAssassin), el mateix Sendmail farà aquesta funció.

Quan actua com a servidor SMTP el servidor de correu també pot realitzar la funcionalitat de MDA (Mail Delivery Agent) i encarregar-se de deixar els missatges a la bústia de cada usuari local.

De fet, si la configuració de correu actual utilitzada és la que es crea per defecte en instal·lar Sendmail, no hi ha cap MDA específic sinó que és el mateix Sendmail el que fa aquesta funció. Això significa que també s’ha d’encarregar de crear les bústies de correu dels usuaris i de gestionar-les (si no és que ja ho fa el mateix sistema operatiu).

Si no hi ha altres agents tipus MDA en funcionament, la creació i la gestió de les bústies d’usuari és missió del servidor de correu.

Un compte de correu no és altra cosa que disposar d’una bústia de correu en el sistema.

Usuaris locals

Si es vol que un usuari local no pugui iniciar una sessió d’usuari en el sistema, se li pot assignar com a shell /sbin/nologin.

Tot usuari de sistemes GNULinux disposa d’un compte local en la màquina on té el compte d’usuari.

Així, un usuari de nom pere en un amfitrió anomenat pc-jocs/ pot rebre correu a l’adreça pere@pc-jocs.

És evident que cada usuari que vol tenir un compte de correu ha de disposar d’una bústia pròpia en la qual el servidor ha de poder desar el correu destinat a l’usuari. L’usuari accedeix a la seva bústia per consultar el seu correu.

Des del punt de vista de la creació de bústies es fa la classificació següent:

  • Usuaris locals del sistema. En sistemes GNU/Linux tots els usuaris del sistema disposen d’una bústia de correu local. Què cal fer perquè els usuaris d’un servidor tinguin correu local? Res. Tots els usuaris locals d’un host tenen una bústia pròpia i tothom s’hi pot adreçar indicant usuari@host. Aquest mecanisme obliga a generar comptes d’usuaris locals en el sistema per tal de poder disposar dels comptes de correu.
  • Usuaris del servei. Hi ha servidors de correu que permeten crear comptes de correu sense necessitat de crear comptes d’usuari locals en el sistema. És a dir, es tracta d’usuaris que existeixen només per al servidor de correu però no per al sistema operatiu.

Usos indeguts del servidor de correu

El problema principal del correu electrònic és el correu brossa o spam, és a dir, el correu no desitjat. Des del punt de vista del client, convé saber filtrar el correu per detectar el correu brossa i informar-ne al servidor (generalment és un webmail). Des del punt de vista del servidor, cal saber filtrar el correu brossa i cal establir mecanismes per no participar en la seva difusió.

Actualment la majoria de serveis de correu del tipus webmail incorporen les dues prestacions següents:

  • Filtrat automàtic de correu brossa. Gmail, per exemple, filtra els correus i intenta detectar quins són brossa i els posa directament en una carpeta amb aquest nom. Gmail aplica regles complexes de filtrat per detectar correus brossa segons el seu criteri. Els usuaris el poden ajudar informant-lo dels missatges que consideren brossa.
  • Cerca automàtica de virus. S’aplica un antivirus als continguts que s’adjunten als fitxers. D’aquesta manera s’evita la propagació indiscriminada de continguts maliciosos.

Accés remot al correu

La manera com els usuaris accedeixen al seu correu ha anat evolucionant al mateix pas que ho ha anat fent la tecnologia. Originalment s’utilitzava simplement l’SMTP (Sendmail, per exemple) i els usuaris havien d’accedir al servidor iniciant una sessió d’usuari per consultar el correu amb eines com Mail. És a dir, els usuaris havien d’anar físicament on hi havia la màquina servidor i iniciar-hi una sessió o bé connectar-s’hi via Telnet.

Però els usuaris volien poder descarregar i enviar des de casa els missatges de correu. El protocol POP d’accés remot a les bústies de correu va proporcionar aquest servei. Els usuaris es connectaven per mòdem, es connectaven al servidor de correu i es descarregaven tot el correu de cop i aprofitaven també per enviar missatges. En aquest model, la gestió dels missatges es feia a casa, el servidor simplement els acumulava per permetre’n la descàrrega. La tecnologia d’accés a internet per mòdem implicava pagar per les trucades. Per tant, l’usuari tenia interès en baixar tot el correu, finalitzar la trucada (per no seguir pagant) i examinar tranquil·lament els missatges sense connexió a internet.

Amb l’aparició de les tarifes planes, els usuaris ja no s’han de preocupar de fer una connexió curta al servidor i poden estar connectats permanentment. El protocol IMAP d’accés a bústies remotes permet l’accés dels clients a les seves bústies realitzant totes les gestions (carpetes, etiquetat, filtrat…) en el mateix servidor. Això resol un dels problemes típics del POP, que és que baixant els missatges en màquines diferents el correu quedava repartit per diferents llocs.

Sempre que es configura un client de correu cal indicar:

  • Servidor de correu entrant: un servidor POP o IMAP des d’on es descarreguen els missatges de l’usuari.
  • Servidor de correu sortint: el servidor SMTP a qui cal lliurar el correu que genera l’usuari per tal que sigui enviat al destinatari.

Actualment, la majoria de clients de correu utilitzen serveis webmail com Gmail, Yahoo o altres. Els clients es connecten al servidor i accedeixen a la seva bústia utilitzant una interfície web. Tota la gestió del correu es fa des d’un navegador.

Servei POP

POP3 és la versió actual del protocol POP. Aquí usem tots dos noms indistintament.

En el model de transport de correu SMTP s’exigeix que el receptor disposi de connexió permanent a internet. Està pensat per a correu entre organitzacions connectades a la xarxa i que disposen d’un servidor de correu que conté les bústies dels usuaris locals de l’organització. Això obliga els usuaris a treballar localment en el servidor per accedir a les seves bústies. Amb la popularització d’internet sorgeix el problema dels usuaris que hi accedeixen per ISP i que no tenen connexió permanent (per exemple, amb mòdem).

POP3 i el correu postal

El POP3 és un mecanisme similar al correu postal. El carter deixa les cartes a la nostra bústia i les recollim quan ens sembla.

S’idea un mecanisme per a l’accés remot als comptes de correu, de manera que l’usuari es connecta quan vol, accedeix a la bústia de correu per recuperar els missatges i finalitza la connexió. POP3 i IMAP són protocols que permeten l’accés remot de clients a les bústies de correu.

POP3 (Post Office Protocol o protocol d’accés simple a les bústies de correu) és un protocol de capa d’aplicació de la pila de protocols TCP/IP (port 110) definit en l’RFC 1939. Permet a un client de correu (MUA) obtenir remotament el correu dipositat en la bústia de l’usuari en un servidor POP3.

Dispersió del correu

Si l’usuari baixa correu POP des de màquines diferents, li queda dispersat. En cada màquina queda desat localment el que s’hi ha baixat.

Normalment, l’usuari utilitza una aplicació client de POP3 (per exemple, Thunderbird) i baixa el correu del servidor POP. Els missatges que es baixen es desen a la màquina de l’usuari (localment) i s’esborren del servidor (es pot configurar si s’esborren o no). Finalment es tanca la connexió.

Funcionament del POP3

Amb el protocol POP3 el client fa una connexió TCP/IP al port 110 del servidor, baixa el correu i tanca la connexió. En aquest procés, client i servidor passen per tres estats (autorització, transacció i actualització) i s’intercanvien ordres i respostes seguint el model de diàleg de Telnet:

  • Ordres. Són ordres de text de quatre caràcters seguides d’espais i els arguments que requereixin. Finalitzen amb un <CRLF>.
  • Respostes. Són una cadena de caràcters que comença per +OK o -ERR més una descripció. Les respostes afirmatives comencen per +OK, i les d’error per -ERR.

Vegeu una llista de les ordres utilitzables en el protocol POP3 agrupades segons l’estat:

Baixar missatges del servidor POP3

Alguns MUA bàsics baixen tots els missatges del servidor de cop. Si es deixen els missatges ja llegits en el servidor, es tornaran a baixar cada cop que s’hi accedeix.

  1. Autorització
    • USER <nomUsuari>. El client s’identifica en el servidor POP indicant el nom d’usuari, que ha de correspondre a una bústia de correu del servidor.
    • PASS <password>. El client s’ha d’autenticar indicant un nom d’usuari i una contrasenya vàlids. L’ordre PASS permet indicar aquesta contrasenya en text net.
    • APOP <nomUsuari> password-md5. Per proporcionar més seguretat en el procés d’autorització, l’usuari pot fer servir l’ordre APOP, que té com a arguments el nom d’usuari i la contrasenya encriptada usant una funció resum o hash, com per exemple MD5.
  2. Transacció
    • STAT. Demana l’estat de la bústia. El servidor retorna el nombre de missatges que conté i el total de bytes que ocupa.
    • LIST [msg]. Llista els missatges o un missatge concret. No en llista el contingut sinó que llista el número de missatge i el nombre de bytes que ocupa cada missatge.
    • RETR msg. Baixa un missatge concret del servidor. Els missatges es poden indicar pel número de missatge.
    • DELE msg. Marca el missatge indicat per ser esborrat. No l’esborra immediatament, només el marca; l’esborra en l’estat final d’actualització. En els MUA que actuen de clients POP és típic permetre configurar si es deixen els missatges en el servidor o s’eliminen. Usualment s’eliminen perquè només hi quedin els nous.
    • NOOP. Aquesta ordre força el servidor a emetre una resposta positiva. Serveix per comprovar que la connexió encara és oberta.
    • RSET. Si s’executa aquesta ordre abans de passar a l’estat d’actualització, RSET desmarca tots els missatges que estaven marcats per esborrar.
    • TOP msg nLin. En lloc de baixar el missatge sencer com fa l’ordre RETR, l’ordre TOP permet baixar-ne les línies inicials. Baixa les capçaleres i les línies inicials (nLin). Aquesta ordre és útil per baixar només les capçaleres (remitents, assumptes…) i per filtrar els missatges a baixar i marcar-los per esborrar-los directament sense baixar-los.
    • UIDL [msg]. Els missatges s’identifiquen pel seu número d’ordre (com fa l’ordre LIST), però aquest número pot variar entre connexions si s’esborren els missatges que el precedeixen. Per identificar de manera única un missatge independentment de la posició que ocupa es pot usar el UID. El UID és únic per a cada missatge d’una bústia. L’ordre UIDL pot llistar els UID i els números d’ordre de tots els missatges o els d’un missatge concret.
    • QUIT. Indica al servidor que el client vol finalitzar la connexió. El servidor passa de l’estat de transacció al d’actualització.
  3. Actualització
    • En aquest estat no hi ha ordres. El servidor elimina els missatges marcats per ser esborrats, emet una resposta positiva al client i tots dos tanquen la connexió.

L’exemple següent correspon a un diàleg mitjançant Telnet entre client i servidor usant el protocol POP. S’hi poden veure les ordres i respostes del protocol:

[root@portatil ~]# telnet localhost 110 
Trying 127.0.0.1... 
Connected to localhost. 
Escape character is ‚^]'. 
+OK POP3 localhost 2007a.104 server ready 
USER pere 
+OK User name accepted, password please 
PASS pere 
+OK Mailbox open, 1 messages 

STAT 
+OK 1 480 
NOOP  
+OK No-op to you too! 
LIST 
+OK Mailbox scan listing follows 
1 480 
. 
RETR 1 
+OK 480 octets 
Return-Path: <root@localhost.localdomain> 
Received: from tftp.server.cat (localhost [127.0.0.1]) 
 by tftp.server.cat (8.14.1/8.14.1) with ESMTP id m5DI4ig8005681 
 for pere@tftp.server.cat; Fri, 13 Jun 2008 20:06:12 +0200 
Date: Fri, 13 Jun 2008 20:04:44 +0200 
From: root <root@localhost.localdomain> 
Message-Id: <200806131806.m5DI4ig8005681@tftp.server.cat> 
Status:

Aquest és un e-mail qualsevol,
el text s'escriu fins acabar 
amb una línia que només conté un punt 
. 

QUIT 
+OK Sayonara 
Connection closed by foreign host.

Hi ha diverses implementacions de servidors POP i cada una compta amb un conjunt d’ordres i extensions pròpies. L’especificació POP3 requereix que s’implementin almenys les ordres STAT, LIST, RETR, DELE, NOOP i REST.

El model POP3

El POP3 és un protocol que permet l’accés remot a les bústies de correu dels usuaris, com l’IMAP. Ni el POP3 ni l’IMAP transporten el correu, aquesta funció la fa l’SMTP, sinó que ofereixen els mecanismes per a que un usuari amb el seu MUA pugui accedir a la seva bústia.

Com la majoria de serveis de xarxa a internet, el protocol POP3 s’estructura seguint l’esquema client/servidor. Aquests són els agents que intervenen en una comunicació POP3:

  • MUA (Mail User Agent o agent d’usuari de correu). L’usuari interactua amb un agent d’usuari per accedir al correu mitjançant POP3. Són agents d’usuari programes com Thunderbird, GetMail, Fetchmail, MS Outlook Express, Eudora, Gmail… Les aplicacions MUA poden ser de text, gràfiques i fins i tot interfícies web. Aquestes aplicacions incorporen el programari necessari per actuar de clients POP3.
  • Client POP3. La part pròpiament encarregada de comunicar amb el servidor POP3 per obtenir els missatges de la bústia de correu de l’usuari és el client POP3. Client i servidor POP3 parlen un llenguatge comú, que és el protocol POP3.
  • Servidor POP3. Per poder implementar l’accés remot al correu cal disposar d’un servidor POP3 en funcionament. Aquest servidor POP3 conté les bústies dels usuaris o hi accedeix. Els missatges es reben mitjançant SMTP, i és un MTA o un MDA el que els diposita a la bústia. El servidor POP3 atén les peticions dels clients POP3 per baixar el correu.

Accés POP3 al correu web

Molts serveis de correu web o webmail permeten baixar correu d’altres serveis usant el protocol POP3 o IMAP. Per exemple, des de Gmail es poden baixar missatges de Yahoo, i viceversa.

Un concepte que ajuda a diferenciar el funcionament de POP3 i IMAP és que en l’esquema de POP3 es considera que l’emmagatzematge del correu es realitza en la màquina de l’usuari. El servidor acumula els missatges nous i aquests es baixen tots a l’amfitrió (host) de l’usuari i s’eliminen del servidor. Per tant, gestionar-los és responsabilitat de l’usuari. Si bé és cert que els missatges es poden desar en el servidor (sense esborrar), no hi ha eines per gestionar-los, tots es troben en una mateixa carpeta. El servidor POP3 ofereix poques funcionalitats: baixar missatges, baixar les capçaleres i esborrar els missatges.

Una sessió POP3 passa per tres estats clarament diferenciats:

  1. Autorització. Un cop feta la connexió TCP/IP pel port 110 entre el client i el servidor POP3, s’entra en l’estat d’autorització. Cal que el client s’identifiqui davant del servidor POP3 indicant el nom d’usuari i la contrasenya.
  2. Transacció. Un cop el client ha estat autoritzat pel servidor, s’entra en l’estat de transacció. En aquest estat el client demana accions (dona ordres) al servidor i aquest les atén. És a dir, en aquest estat el client descarrega el correu, marca missatges per esborrar, demana les capçaleres dels missatges, en fa una llista per ordre… El client finalitza l’estat de transacció utilitzant l’ordre QUIT.
  3. Actualització. El servidor entra en l’estat d’actualització en rebre l’ordre QUIT del client. Elimina els missatges marcats per esborrar (que fins ara no s’havien eliminat) i envia un OK al receptor. Ara tots dos poden finalitzar la comunicació.

Servei IMAP

IMAP (Internet Message Access Protocol o protocol d’accés a missatges d’Internet) és un protocol de capa d’aplicació del model TCP/IP que proporciona a l’usuari accés remot a la seva bústia de correu. L’IMAP sorgeix com a resposta al problema d’accés al correu des de diferents ordinadors utilitzant POP.

El POP és un protocol pensat per baixar el correu del servidor al PC local de l’usuari i poder-lo manipular després sense connexió a internet. Usant POP es considera que el correu resideix en l’equip de l’usuari, que baixa tot el correu de cop cada vegada que es connecta al servidor.

Quan els usuaris es van acostumar a consultar el correu remotament, ho van començar a fer des d’equips diferents: a casa, a la feina, de vacances… Cada cop que ho feien deixaven part del seu correu en llocs diferents. El que s’havien baixat a casa no es podia consultar a la feina, i viceversa. Un cop els usuaris es van acostumar a disposar de connexió d’internet més assíduament, calia un mecanisme més evolucionat d’accés remot al correu.

Ni l’IMAP ni el POP són protocols de transmissió de correu. Usualment és el protocol SMTP qui fa aquesta funció.

Per obtenir més informació sobre l’especificació del protocol IMAP en els RFC 1064 i 3501, aneu a la secció “Adreces d’interès” del web d’aquest crèdit.

L’IMAP presenta un enfocament diferent. Els missatges de correu es dipositen en el servidor i allà s’emmagatzemen en carpetes (o folders o mailboxes) i on es manipulen. L’usuari els pot baixar localment, però com a còpia temporal. Per tant, tota la gestió dels missatges de correu té lloc en el servidor. Això fa de l’IMAP un protocol més complex que el POP.

L’IMAP és un protocol de capa d’aplicació de la pila de protocols TCP/IP (port 143) definit en el document RFC 1064. Permet a un client de correu (MUA) obtenir remotament el correu dipositat en la bústia de l’usuari en un servidor IMAP.

L’IMAP sorgeix el 1986 amb el nom d’Interim Mail Access Protocol, que en la versió següent es canvia per Interactive Mail Access Protocol (document RFC 1064), i que finalment serà Internet Mail Access Protocol. L’evolució actual és IMAP versió 4 revisió 1 (març de 2003), corresponent al document RFC 3501 (del qual també s’han fet actualitzacions i extensions) que s’ha creat sota els auspicis de l’IETF.

Difusió del servei IMAP

Avui en dia l’IMAP està molt estès, però no és estrany trobar ISP i portals de correu web que permeten baixar el correu únicament mitjançant el POP.

El protocol IMAP està pensat per tenir en el servidor tot el correu de l’usuari organitzat en carpetes jeràrquiques de manera indefinida. Es permet la manipulació remota de les carpetes i els missatges. Tant les unes com els altres es poden crear, modificar i suprimir. Els missatges no s’esborren si no ho indica explícitament l’usuari. A més, aporta la funcionalitat de cerca i filtratge de missatges directament en el servidor. És a dir, no cal baixar els missatges per buscar els que compleixen unes condicions determinades. El protocol permet l’accés concurrent de diversos usuaris a la mateixa bústia, i el servidor pot notificar l’arribada de correu nou. Els missatges multipart es poden baixar parcialment, es poden buscar parts i baixar només les que interessin. Tots els missatges i les bústies tenen indicadors d’estat que descriuen, per exemple, si el missatge s’ha llegit, si s’ha contestat, si és nou…

El model IMAP

Com la majoria de serveis de xarxa a internet, el protocol IMAP s’estructura seguint l’esquema client/servidor. Aquests són els agents que intervenen en una comunicació IMAP:

  • MUA (Mail User Agent o agent d’usuari de correu). L’usuari interactua amb un agent d’usuari per accedir al correu mitjançant l’IMAP. Són agents d’usuari programes com Thunderbird, GetMail, Fetchmail, MS Outlook Express, Eudora o Gmail. Les aplicacions MUA poden ser de text, gràfiques i fins i tot d’interfície web. Aquestes aplicacions disposen del programari necessari per actuar com a clients IMAP.
  • Client IMAP. La part pròpiament encarregada de comunicar amb el servidor IMAP per obtenir els missatges de la bústia de correu de l’usuari és el client IMAP. Client i servidor IMAP parlen un llenguatge comú: el protocol IMAP.
  • Servidor IMAP. Per implementar l’accés remot al correu cal disposar d’un servidor IMAP en funcionament. Aquest servidor IMAP conté les bústies dels usuaris o hi accedeix. Els missatges es reben per SMTP i és un MTA o un MDA els que els diposita a la bústia. El servidor IMAP atén les peticions dels clients IMAP per gestionar el correu.

Observeu el model funcional del protocol IMAP en la figura, on mitjançant el seu MUA un usuari descarrega el correu del servidor amb el POP o IMAP.

Figura Model funcional del protocol IMAP

En el protocol IMAP s’observen quatre estats:

  1. No autenticat. Quan s’estableix la connexió TCP/IP entre el client i el servidor s’entra en aquest estat. El client s’ha d’autenticar en el servidor, ha d’acreditar ser un usuari vàlid. Per fer-ho ha d’indicar el nom d’usuari i la contrasenya.
  2. Autenticat. Un cop autenticat i abans de poder manipular missatges, ha de seleccionar la bústia (carpeta, folder o mailbox) amb la qual operarà. En aquest estat pot manipular les carpetes (crear-ne, esborrar-les, modificar-les i veure’n l’estat), però no els missatges fins que no se n’ha seleccionada una.
  3. Seleccionat. Un cop s’ha seleccionat una carpeta, s’entra en aquest estat, que permet la manipulació dels continguts de la carpeta.
  4. Logout. En aquest estat es tanca la connexió. S’hi pot arribar tant per petició del client com per decisió unilateral del servidor.

El servidor IMAP emmagatzema permanentment els missatges de l’usuari. Per fer-ho utilitza un sistema de bústies o carpetes jeràrquiques i atributs que descriuen tant l’estat de les bústies com dels missatges:

Carpetes

Hi ha una bústia o mailbox que és la de l’usuari. Dins d’aquesta bústia, s’hi poden crear carpetes indicades de manera relativa, com els directoris d’una estructura de fitxers. Les carpetes disposen almenys de dos atributs:

  • Next UID (UID següent). Indica l’UID que s’assignarà al missatge següent.
  • UID Validity Value (UIDVALIDITY). És un valor d’identificador únic assignat a la carpeta seleccionada. La combinació de nom de carpeta UIDVALIDITY i UID identifica de manera perpètua un missatge en el servidor.

Atributs de missatge

Els missatges tenen atributs que s’emmagatzemen en les pròpies bústies que en faciliten la gestió:

  • UID. Identificador únic del missatge. És un número de 32 bits que s’assigna ascendentment a mesura que arriben missatges (no és necessàriament correlatiu). Això permet al servidor saber, en una bústia, a partir de quin número de missatge hi ha els missatges nous (en POP això no és possible).
  • Número de seqüència. Número relatiu del missatge dins de la bústia (de 1 a n per a n missatges). Els números de seqüència s’assignen correlativament segons el UID en ordre ascendent i varien en esborrar-se i afegir-se nous missatges.
  • Indicadors. Els indicadors, flags o banderes informen de l’estat del missatge. Per exemple, si s’ha llegit o esborrat. Els indicadors són: Seen (llegit), Answered (respost), Flagged (marcat), Deleted (esborrat), Draft (esborrany) i Recent (nou).
  • Data interna. Data i hora d’arribada del missatge al servidor IMAP (no és la data i hora de l’emissió del missatge que hi ha en la capçalera Date).
  • Longitud. Nombre de bytes del missatge.
  • Estructura del sobre. Representació analitzada de les capçaleres del missatge.
  • Estructura del cos. Representació analitzada de l’estructura MIME del cos del missatge.
  • Parts de text del missatge. Per permetre la cerca de les diferents parts de text del missatge. Es pot fer l’accés segons la part de capçaleres, cos, part del cos MIME i capçalera MIME.

Funcionament de l'IMAP

Diferència entre POP i IMAP

En el protocol POP el servidor només pot respondre a peticions del client, però no pot prendre la iniciativa. En el protocol IMAP sí.

Amb el protocol IMAP el client fa una connexió TCP/IP al port 143 del servidor i s’inicia un diàleg entre el client i el servidor en què tots dos poden prendre la iniciativa. En aquest procés se succeeixen els quatre estats del protocol IMAP (no autenticat, autenticat, seleccionat i logout) i s’intercanvien ordres i respostes seguint el model de diàleg de Telnet:

  • Ordres. Són ordres de text que inclouen un tag (o etiqueta curta) inicial, l’ordre i els seus arguments. Cada ordre comença amb una etiqueta inicial diferent per diferenciar-la de les altres ordres i aquesta és obligatòria. Quan el servidor emeti la resposta final de l’ordre i indiqui si s’ha realitzat correctament o no, ho farà mostrant l’etiqueta de l’ordre a la qual respon. Per exemple, es pot usar a001 per a la primera ordre, a002 per a la segona… El client pot enviar ordres sense esperar que finalitzin les anteriors.
  • Respostes. El servidor pot enviar dades al client tant com a resposta a una ordre com de manera unilateral (per exemple, per informar que hi ha correu nou). El client ha d’estar en tot moment a punt per rebre aquestes dades. Que el servidor enviï dades al client no significa que l’execució de l’ordre del client hagi finalitzat. Només es dona per finalitzada quan el servidor emet una resposta amb la mateixa etiqueta que l’ordre del client. El servidor pot processar una ordre abans d’acabar de processar l’ordre anterior.

Vegeu les ordres utilitzables en el protocol IMAP agrupades segons l’estat:

Avantatges de l'IMAP respecte al POP

Un dels avantatges de l’IMAP respecte al POP és que el servidor sap a partir de quin número de missatge hi ha els missatges nous (RECENT).

  1. Ordres generals (qualsevol estat)
    • Capability. Llista les capacitats del servidor. Permet al client saber quines són les prestacions del servidor.
    • Noop. Exigeix una resposta afirmativa del servidor. Permet al client saber si encara es manté la connexió.
    • Logout. És la notificació del client al servidor per fer-li saber que vol finalitzar la connexió.
  2. No autenticat
    • Authenticate <tipus>. Indica al servidor el mecanisme d’autenticació a utilitzar.
    • Login <user> <password>. El client s’identifica en el servidor indicant el nom d’usuari i la contrasenya. El format varia (text net, hash MD5…) segons el tipus d’autenticació utilitzat.
  3. Autenticat
    • Select <bústia>. Selecciona la bústia amb què ha d’operar. En fer-ho, el servidor emet una resposta no etiquetada en què informa dels atributs (flags) de la bústia, del nombre de missatges que conté (exists) i del nombre de missatges recents (recent). També pot indicar el número del primer missatge no llegit (nseen) i la llista d’atributs que es poden modificar (permanent flags).
    • Examine <bústia>. Realitza la mateixa funció que l’ordre Select però només de lectura.
    • Create <bústia>. Crea la bústia amb el nom indicat.
    • Delete <bústia>. Esborra la bústia indicada.
    • Rename <bústia> <nomNou>. Permet assignar un nom nou a la bústia.
    • Subscribe <bústia>. Les bústies poden estar actives o no. Aquesta ordre les activa.
    • Unsubcribe <bústia>. Permet desactivar una bústia.
    • List <bústia> <criteri>. Llista les bústies que compleixen el criteri indicat dins de la bústia seleccionada.
    • Lsub <bústia> <criteri>. Realitza la mateixa funció que l’ordre anterior però només per a les bústies actives.
    • Status <bústia> <atributs>. Permet conèixer l’estat d’una bústia per mitjà dels seus atributs. Els atributs són els següents:
      • MESSAGE: nombre de missatges dins la bústia
      • RECENT: nombre de missatges recents (nous)
      • UIDNEXT: UID assignat al següent missatge que arribi a la bústia
      • UIDVALIDITY: valor UID de la bústia
      • UNSEEN: nombre de missatges no llegits
    • Append bústia [atributs] [data-hora] literal. Permet afegir un text al final de la bústia com si es tractés d’un missatge nou. El missatge s’afegeix amb la data, hora i atributs indicats.
  4. Seleccionat
    • Check. El client sol·licita al servidor que es faci un control de la bústia en un moment determinat.
    • Close. Tanca la bústia i elimina tots els missatges que conté que tenen l’indicador d’esborrament (deleted) activat.
    • Expugne. Permet esborrar els missatges que tenen l’atribut d’esborrament (deleted) activat sense que calgui tancar la bústia.
    • Search [charset] criteri. Permet buscar missatges dins de la bústia que compleixen el criteri de cerca indicat.
    • Fetch dades atributsRecuperació. Permet recuperar un conjunt de missatges totalment o parcialment segons els atributs de recuperació indicats.
    • Store conjuntMissatges atributs. Permet alterar les dades d’atributs associats a un conjunt de missatges en una bústia.
    • Copy conjuntMissatges bústia. Copia un conjunt de missatges al final de la bústia indicada.
    • UID ordre. Retorna l’UID d’un missatge. S’utilitza conjuntament amb les ordres COPY, FETCH, STORE o SEARCH per retornar els UID manipulats.
  5. Experimental
    • X<ordre>. Es poden desenvolupar ordres experimentals fora de l’especificació IMAP. Per fer-ho cal que les ordres comencin amb XnomOrdre. D’aquesta manera s’evita que es produeixin conflictes amb ordres futures.

En l’exemple següent podeu veure tot el diàleg client/servidor d’una sessió IMAP utilitzant Telnet:

[root@portatil ~]# telnet localhost 143 
Trying 127.0.0.1... 
Connected to localhost. 
Escape character is ‚^]'. 
* OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS 
STARTTLS] localhost IMAP4rev1 2007a.403 at Sat, 14 Jun 2008 
13:16:47 +0200 (CEST) 

a003 LOGIN pere pere 
a003 OK [CAPABILITY IMAP4REV1 LITERAL+ IDLE UIDPLUS NAMESPACE 
CHILDREN MAILBOX-REFERRALS BINARY UNSELECT ESEARCH WITHIN SCAN 
SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User 
pere authenticated

a004 SELECT inbox 
* 4 EXISTS 
* NO Mailbox vulnerable - directory /var/spool/mail must have 
1777 protection 
* 4 RECENT 
* OK [UIDVALIDITY 1213385060] UID validity status 
* OK [UIDNEXT 6] Predicted next UID 
* FLAGS (\Answered \Flagged \Deleted \Draft \Seen) 
* OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft 
\Seen)] Permanent flags 
* OK [UNSEEN 1] first unseen message in /var/spool/mail/pere 
* NO Mailbox vulnerable - directory /var/spool/mail must have 
1777 protection 
a004 OK [READ-WRITE] SELECT completed

a005 FETCH 1 rfc822.text 
* 1 FETCH (RFC822.TEXT {63} 
exemple de missatge de la usuària anna 
a l'usuari pere 
adéu 
) 
a005 OK FETCH completed

a006 LOGOUT 
* BYE portatil IMAP4rev1 server terminating connection 
a006 OK LOGOUT completed

Clients de correu

L’accés a les bústies de correu electrònic a través de les ordres i comandes que ofereixen els protocols IMAP i POP és complex i per a un usuari normal, impracticable. No obstant, existeix tot un conjunt de programari que automatitza totes aquestes tasques i les presenta en un entorn més amigable. Aquest programari s’anomena client de correu. Existeixen clients de correu de característiques molt diverses.

En general es poden classificar en:

  • Clients de text. Utilitats Unix i GNU/Linux de tota la vida que permeten generar missatges de correu i accedir a la bústia de correu pròpia. Són utilitats de consola, és a dir, de text. N’hi ha de format ben simple, com l’ordre mail, i evolucions que permeten treballar amb programes de menús en color també en entorn de consola, com Mutt, Alpine…
  • Clients gràfics. Amb la popularització dels entorns gràfics van sorgir programes client de correu com Eudora, Evince, Outlook o Thunderbird. Durant un temps aquests programes eren l’eina més usada pels usuaris per accedir a les seves bústies de correu.
  • Client web. Actualment la majoria de comptes de correus dels usuaris són de tipus correu web, principalment en serveis gratuïts com Gmail, Yahoo o Hotmail. Fins i tot els entorns corporatius utilitzen correu web hostatjat en serveis externalitzats.

Correu encriptat i signat

Les comunicacions per correu electrònic s’han tornat cada vegada més importants en la nostra vida diària, no només pels correus amb acudits, presentacions gracioses o crítiques al govern. També són imprescindibles per al funcionament de moltíssimes empreses i organitzacions. De fet, molta documentació que abans es feia per escrit ara es fa telemàticament per correu electrònic.

Això fa necessari poder estar segurs de la identitat de l’emissor i del receptor dels correus. En entorns de seguretat més exigents fins i tot es pot requerir l’encriptació del contingut per evitar que sigui accessible per tercers.

El concepte clau per a la confiança en les comunicacions per correu electrònic és la signatura digital, que permet assegurar que un emissor és qui diu ser i garanteix també que el contingut del missatge no s’ha alterat per tercers. Per implementar la signatura digital i l’encriptació cal utilitzar certificats digitals.

Consulteu a “Annexos” l’explicació més àmplia de conceptes globals de seguretat i documents específics per a PGP, S/MIME i certificats digitals.

És important tenir clars els conceptes generals de seguretat per poder diferenciar els termes relacionats amb la seguretat dels quals no es coneix el significat amb exactitud.

Els puntals de la seguretat en el correu són: autenticació, integritat, no repudi i encriptació. Es poden crear parelles de claus públiques i privades (certificats digitals) i hi ha diversos formats de claus existents.

L’MTA i els servidors de correu transporten missatges independentment del fet de que estiguin encriptatts o signats. Són els clients de correu els que han de proporcionar a l’usuari la capacitat d’encriptar i signar missatges .

Per poder gestionar correu signat i encriptat cal utilitzar clients de correu que permetin fer aquestes funcions. Cada usuari ha de disposar dels certificats digitals apropiats. Per al protocol de transport de correu SMTP i al servidor de correu (per exemple, Sendmail) que el missatge que processen sigui encriptat i signat és indiferent, igual que al carter no li afecta que el contingut d’una carta estigui encriptat amb una clau secreta o que la carta porti imprès el segell d’una entitat. Són els clients de correu, com Thunderbird, els que han de tenir la capacitat de gestionar aquest tipus de correu. Per exemple, a Thunderbird cal afegir-li programari addicional (Open PGP o S/MIME, per exemple) per permetre-li signar i encriptar missatges.

Les dues tecnologies de signat i encriptat de correu tractades aquí són:

  • Open PGP. Aquesta tecnologia permet generar missatges de correu encriptats i signats i, lògicament, desxifrar-ne el contingut i verificar les signatures. Es basa en el programa PGP (Pretty Good Privacy), desenvolupat per Phil Zimmermann. Utilitza el model de seguretat anomenat web of trust, en què cada usuari és el responsable de la gestió de la confiança en els certificats dels altres usuaris.
  • S/MIME. Aquest estàndard proporciona les mateixes característiques de signatura digital i encriptació (i a la inversa) que Open PGP, però requereix un altre format per als certificats digitals. El model de seguretat que utilitza és el PKI (Public Key Infrastructure), en què existeix una estructura piramidal d’entitats de certificació (Certification Authority, CA) que determinen la confiança en els certificats digitals. Aquest PKI és el model en què es basen la majoria de protocols de seguretat d’internet, com HTTPS o SMTPS, que utilitzen SSL o TLS. Usualment els navegadors web incorporen per defecte els certificats de les CA més destacades del món.

Seguretat en el correu

L’intercanvi de missatges de correu es produeix utilitzant protocols SMTP, POP i IMAP, que són insegurs, és a dir, que transporten el contingut en forma de text pla. Per tant, qualsevol intermediari en la xarxa pot monitorar (usant un sniffer o rastrejador) el contingut dels missatges. Qualsevol eina tipus Wireshark permet fer un seguiment dels continguts de qualsevol protocol TCP en text pla.

Monitoratge de contingut

Un exemple típic de monitoratge és monitorar el diàleg entre dos amfitrions usant Wireshark. Permet fer un seguiment de les trames de xarxa i utilitzant l’opció de seguiment del flux TCP anomenada Follow TCP Stream es pot observar clarament el text de tot el diàleg efectuat.

Això significa que quan dos interlocutors intercanvien missatges per qualsevol xarxa el contingut del seu diàleg pot ser monitorat per tercers. I no només això, sinó que la conversa pot ser falsejada per aquests tercers (el conegut com a man-in-the-middle). És a dir, un usuari pot creure que està dialogant amb la seva entitat bancària quan en realitat ho està fent amb uns impostors.

Propietats de seguretat

Els aspectes de seguretat desitjables en la comunicació entre dos interlocutors són:

  • Confidencialitat (encriptació)
  • Autenticitat
  • No-repudi
  • Integritat

Un error comú es barrejar aquests conceptes i pensar que tots quatre van junts, i no sempre és així. Cal aplicar a cada cas el tipus de seguretat que faci falta.

Confidencialitat

Si un emissor vol enviar un missatge secret a un receptor de manera que únicament aquest el pugui entendre, ha d’encriptar el missatge. El destinatari ha de conèixer la clau o ha de disposar d’un mecanisme per desencriptar el missatge i obtenir-ne el contingut original.

Encriptar és codificar el missatge utilitzant algun tipus de clau o mecanisme per fer inaccessible el missatge a qualsevol usuari que no sigui el destinatari.

Que el missatge estigui encriptat garanteix que només l’emissor és capaç d’entendre’n el contingut (se suposa que han acordat el mecanisme per desencriptar). Ara bé, pot estar segur el destinatari que el missatge prové realment de qui creu que prové? Pot estar segur que el missatge no ha estat alterat?

Encriptar un missatge proporciona confidencialitat, però no és un mecanisme que ofereixi la seguretat que l’emissor és qui diu ser ni que el missatge és tal com era en l’origen (sense modificacions posteriors).

Autenticitat

Quan un receptor rep un missatge del banc informant-lo que ha de fer un pagament o que ha d’enviar el número de la seva targeta de crèdit per una raó determinada, però no pot estar segur el receptor que el missatge procedeix realment del banc.

L’autenticació és la característica de seguretat que permet a un receptor estar segur que el missatge prové de qui diu provenir. Alhora, proporciona a l’emisor la garantia que el receptor sap del cert que el missatge li ha enviat ell.

No-repudi

Si un emisor envia un missatge autenticat a un emissor no té manera legal de desdir-se d’haver-lo enviat. Imagineu que un directiu d’una empresa envia un missatge inapropiat a un treballador. Si el missatge és autenticat, el directiu no pot negar legalment que l’ha enviat. El mateix pot passar si l’empresa A envia un correu electrònic a un client oferint-li els productes a meitat de preu, i després intenta retractar-se’n dient que el correu no era seu. Si el missatge és autenticat, queda legalment demostrat que l’empresa A n’és l’emissora.

Aquesta característica que impedeix que l’emissor pugui negar haver enviat el missatge s’anomena no-repudi.

Cal un mecanisme de seguretat que permeti a un emissor enviar missatges de manera que els receptors tinguin la certesa absoluta que l’emissor és qui diu ser.

Una confusió habitual és creure que per establir seguretat també cal encriptar. Això no és cert. Una administració pública, per exemple, pot enviar missatges als ciutadans garantint l’autenticitat del missatge, però no li cal encriptar els missatges, no li cal fer-los secrets.

Integritat

No n’hi ha prou amb l’encriptació i l’autenticació per establir una comunicació cent per cent segura. S’ha d’assegurar que el missatge no ha estat alterat, és a dir que no s’han eliminat o afegit parts, ni tampoc que se n’hagin modificat. S’ha d’assegurar que el missatge està íntegre. L’encriptació i l’autenticació asseguren que el missatge procedeix de qui diu procedir i que no ho veu ningú més, però no s’assegura que no hagi estat modificat.

La integritat és la propietat de seguretat que garanteix que el missatge no ha estat alterat i que arriba al destinatari tal com s’ha generat en l’origen.

Per implementar integritat no cal encriptar els missatges, són coses independents. En canvi, la integritat i l’autenticitat van juntes, és a dir, tenint l’una també s’obté l’altra (i viceversa).

Implementació de seguretat

Per implementar seguretat en la comunicació avui en dia s’utilitzen habitualment els mecanismes de certificats digitals basats en la criptografia de clau asimètrica. És a dir, basats en el fet que cada interlocutor disposa d’una clau privada (coneguda i accessible només per ell) i d’una clau pública o certificat (coneguda per tots els interlocutors).

Els certificats són les claus públiques signades, avalades, per una entitat de certificació o CA (Certification Authority).

Per implementar seguretat els interlocutors disposen de: una clau privada i un certificat, o clau pública signada per una CA.

Vegeu com s’implementa la seguretat de clau pública/privada:

  • Encriptació
  • Sigatura o certificat digital

En realitat, la qüestió de la seguretat és més complexa si s’hi afegeixen les CA, els anells de clau, el sistema PKI… En aquesta unitat es tracta la versió més simple d’aquest model i s’estudia només allò estrictament necessari per a la comunicació segura entre dos interlocutors.

Cal tenir molt present que la clau privada és això, privada: només la coneix i només hi pot accedir el seu propietari. Mai es comunica a un tercer. En canvi, la clau pública és coneguda per totes les parts que intervenen en la comunicació. De fet, si els interlocutors no la coneixen cal enviar-los-la per tal que la tinguin. Si no fos així, el sistema de clau pública/privada no funcionaria.

La parella clau pública/privada permet encriptar i signar. Quan se n’utilitza una per fer una acció, cal l’altra per desfer-la. Funcionen conjuntament: si una fa, l’altra desfà, i a l’inrevés.

Mala interpretació del funcionament de les claus

Un error típic és creure que cada clau només pot fer una cosa i dir que “la clau privada sempre encripta i signa i la pública desencripta i verifica”. No va així. Segons l’acció a fer se n’utilitza una o l’altra (i per desfer l’acció sempre cal aplicar la contrària).

Encriptació

Un emissor A vol enviar un missatge encriptat a un destinatari B, de manera que únicament aquest tingui la capacitat de conèixer el contingut real del missatge.

Per fer-ho, l’emissor encripta el missatge amb la clau pública del destinatari. De fet, qualsevol emissor del món ho pot fer, precisament perquè la clau pública del destinatari és pública.

Un cop encriptat el missatge, únicament el pot desencriptar qui tingui la clau privada associada a la clau pública usada per encriptar-lo. És a dir, només podrà desencriptar el missatge el destinatari.

Publicació de la clau pública

La clau pública ha de ser coneguda per tots els participants en la comunicació. Els mecanismes per donar-la a conèixer són:

  • Publicar-la en un servidor públic de claus.
  • Enviar la clau als destinataris als quals s’adreça l’emissor (amics, coneguts i saludats).
  • Adjuntar la clau pública als missatges.

Què coneix l’emissor del destinatari? La seva clau pública. De manera que l’emissor encripta el missatge amb la clau pública del destinatari. De fet, qualsevol emissor del món ho pot fer, precisament perquè la clau pública del destinatari és pública.

Un cop encriptat el missatge, la resta (inclòs l’emissor) no poden desencriptar-lo. Únicament el pot desencriptar qui tingui la clau privada associada a la clau pública usada. És a dir, només podrà desencriptar el missatge qui disposi de la clau privada del destinatari B, és a dir que només el destinatari podrà fer-ho.

Qualsevol pot encriptar un missatge usant la clau pública del destinatari, que precisament és pública. Únicament el destinatari pot desencriptar el missatge usant la seva clau privada.

Signatura

Signar un missatge proporciona integritat, autenticació i no-repudi simultàniament. Quan un missatge està signat per l’emissor és irrefutable que el missatge procedeix d’ell i, a més, garanteix que no s’ha modificat per tercers. El receptor pot verificar així que el missatge és autèntic.

El procés físic de signar el missatge consisteix a afegir al missatge el certificat digital de l’emissor. De vegades el fet de signar un missatge s’anomena certificar-lo o es parla de missatge amb certificat digital.

El funcionament és força similar al de l’encriptació, però en aquest cas l’emissor signar un missatge utilitzant la seva pròpia clau privada, i el receptor utilitza la clau pública de l’emissor per verificar el missatge.

Com que les parelles de claus pública/privada només funcionen conjuntament, la verificació només serà correcta si el missatge s’ha encriptat amb la clau privada corresponent. És a dir, la verificació amb la clau pública de l’emissor A només funcionarà si el missatge s’ha signat amb la clau privada de l’emissor A.

Qualsevol pot verificar la signatura d’un missatge usant la clau pública de l’emissor. Únicament l’emissor pot signar el missatge usant la seva clau privada.

El procés de signatura és complementari al de l’encriptació. El primer proporciona integritat, autenticació i no-repudi, mentre que el segon proporciona confidencialitat.

Que un missatge estigui signat no significa que sigui secret. Perquè sigui secret també ha d’estar encriptat.

El procés mecànic de signar un missatge consisteix a aplicar la clau privada al missatge. Això comporta els processos següents:

  • Integritat: no es codifica tot el missatge amb la clau privada, ja que això implica un sobrecost de temps i esforç de càlcul. El procés tècnic que es fa és generar un hash o resum del missatge i signar-lo. Si el missatge es modifiqués, el resum no coincidiria amb el missatge.
  • Autenticitat: per autenticar el missatge s’adjunta el certificat o clau pública de l’emissor avalat per una autoritat de certificació o CA. Aquest certificat i el resum van codificats amb la clau privada. No tot el missatge, només aquesta part. Així el receptor verifica amb la clau pública de l’emissor que el certificat de l’emissor és vàlid i que el hash també.

Tècniques de 'hash' o resum

Una funció resum (hash) és una funció que permet reduir qualsevol informació de qualsevol mida a un valor de mida fixa. Entre les seves utilitats hi ha la validació de la integritat de fitxers (tant per temes d’autenticitat com de comprovació d’errors en la transmissió), autenticació amb signatura digital, i en programació i base de dades per a la indexació de les dades.

Són funcions exhaustives, i moltes vegades s’anomenen de direcció única, ja que la funció inversa no dona un únic resultat. A més, el càlcul de la funció inversa és costós. Per exemple, per calcular el valor d’origen normalment es recorre a atacs de força bruta.

Algunes funcions resum són els CRC (Cyclic Redundancy Checks), els MD (Message Digest) i els SHA (Secure Hash Algorithm).

En definitiva, el procés de signar un missatge o incorporar al missatge una signatura digital consta dels passos següents:

  1. Es genera un hash, message digest o fingerprint del missatge.
  2. S’encripta el resum amb la clau privada de l’emissor. Això és la signatura digital.
  3. El destinatari rep el missatge i fa un nou resum, és a dir, torna a fer el hash basant-se en el contingut del missatge rebut.
  4. La signatura digital rebuda (resum encriptat) es desencripta amb la clau pública de l’emissor.

Per tant:

  • Els dos resums han de ser iguals: això garanteix l’autenticació i la integritat.
  • Es garanteix l’autenticació: només l’emissor pot haver generat el missatge si es pot desencriptar per la clau pública de l’emissor.
  • Es garanteix la integritat: ningú més pot haver modificat el missatge perquè això hauria modificat el resum i no hi ha ningú més que tingui la clau privada de l’emissor per tornar-lo a signar.
  • No cal encriptar tot el missatge, només el resum, que és la part que garanteix que no s’ha modificat.

Servidor de correu segur

Els protocols de correu analitzats en aquesta documentació són tots protocols de transport d’informació en text pla. Qualsevol comunicació SMTP, POP o IMAP es fa en text pla i pot ser monitorada per tercers que tinguin accés als nodes de xarxa per on passen aquestes comunicacions. De fet, s’han vist exemples de monitoratge de les converses TCP utilitzant Wireshark. Aquesta feblesa no és exclusiva dels protocols de correu, sinó que és comuna a la majoria de protocols d’Internet, com HTTP, FTP o TFTP.

Els protocols de correu tenen mecanismes similars als usats en HTML per establir canals de comunicació segurs:

  • SMTPS: no és un protocol diferent de l’SMTP ni una extensió seva, és simplememnt una manera d’anomenar l’ús d’SMTP a través d’SSL o TLS. Així com l’usuari estableix comunicacions HTTP segures usant HTTPS, pot establir un transport de correu segur amb SMTPS. El protocol és el mateix, però viatja per SSL, que li proporciona seguretat. Per usar SMTPS cal comunicar-se per un port diferent del 25, en concret el 465. Això representava un problema, ja que el sistema de correu a Internet es basa majoritàriament en la utilització del port 25, però aquest problema es va resoldre amb la utilització d’STARTTLS
  • POPS: com passa amb HTTPS i SMTPS, POPS no és un protocol pròpiament dit, sinó tan sols la utilització de l’accés remot a bústies POP amb transport segur SSL o TLS. Utilitza el port 995 en lloc del port 110 clàssic de POP
  • IMAPS: és també la manera d’anomenar el protocol IMAP quan viatja per una capa de transport segur com SSL o TLS. El port utilitzat per IMAP sobre SSL és el 993

Els acrònims SMTPS, POPS i IMAPS indiquen la utilització del protocol usant una capa de transport segura SSL o TLS, cosa que permet una comunicació encriptada que no pot ser monitorada per tercers (com passa amb HTTP sobre SSL, que s’anomena HTTPS).

En la figura es pot veure la pantalla de Thunderbird de creació d’un compte de correu de Gmail. Observeu que el correu entrant utilitza IMAP sobre SSL/TLS al port 993 del servidor imap.googlemail.com, que és el servidor de correu de Gmail. També es configura com a correu sortint el servidor SMTP sobre SSL/TLS de Google. S’utilitza el port 465 del servidor smtp.googlemail.com, que és el nom de l’amfitrió de Gmail que fa la funció de servidor SMTP.

Figura Configuració de compte de correu a Gmail

L’exemple següent mostra com s’inicia un diàleg en mode consola amb un servidor SSL. S’utilitza una de les utilitats de l’ordre openssl, que permet actuar com a client SSL. En aquest exemple es contacta el servidor IMAP de Gmail:

[root@host ~]# openssl s_client -crlf -connect imap.gmail.com:993
[root@host ~]# openssl s_client -crlf -connect smtp.googlemail.com:465
Anar a la pàgina anterior:
Referències
Anar a la pàgina següent:
Activitats