[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


205. Introduzione alla gestione della posta elettronica

Quando si gestisce un servente, sia in una rete locale, sia quando questo è inserito nella rete globale, è importante conoscere almeno qualche concetto legato alla trasmissione della posta elettronica. Generalmente, le distribuzioni GNU/Linux sono impostate in modo da garantire il funzionamento di questo sistema, ma i problemi di sicurezza che si presentano quando si amministra un servente di questo tipo, impongono una conoscenza maggiore rispetto alla semplice messa in funzione del servizio.

205.1 Schema essenziale

Generalmente, lo schema essenziale di funzionamento del sistema di trasferimento dei messaggi di posta elettronica è basato sul protocollo SMTP (Simple Mail Transfer Protocol), e utilizza fondamentalmente due componenti: MTA (Mail Transport Agent), che include anche l'MDA (Mail Delivery Agent), e MUA (Mail User Agent). Il primo dei due è il sistema che si occupa del trasferimento e della consegna dei messaggi, mentre il secondo è il programma che viene utilizzato per comporre i messaggi e passarli all'MTA.

 Mittente
    |
    V
+-------+          +-------+
|       |   stdin  |       |
| M U A |- - - - ->| M D A |
|       |	   |       |			Consegna all'utente
+-------+	   +-------+			destinatario
    V		       V			       ^
    |		       |			       |
   SMTP		       |			       |
    |  +- - - SMTP - - + 			       |
    V  V                                               |
+--------+		 + - - - - +	 	   +--------+
| M T A  | 		 :  M T A  :		   | M T A  |
|servente|-----SMTP----->:servente :-----SMTP----->|servente|
|  SMTP  |		 :  SMTP   :		   |  SMTP  |
+--------+		 + - - - - +		   +--------+

Figura 205.1: Schema semplificativo del meccanismo di trasmissione della posta elettronica tra MTA (MDA) e MUA.

Eventualmente, l'MDA è un componente particolare di un MTA che permette di provvedere alla consegna di un messaggio localmente, oppure alla trasmissione attraverso il protocollo SMTP, dopo averlo ricevuto dallo standard input. I programmi MUA più semplici dipendono dall'MDA, non essendo in grado di provvedere da soli a instaurare una connessione SMTP con un servente di posta elettronica.

La sequenza di MTA, o meglio, di serventi SMTP utilizzati per trasmettere il messaggio a destinazione, dipende dall'organizzazione di ognuno di questi. La situazione più comune è quella in cui ne sono coinvolti solo due: quello utilizzato per iniziare la trasmissione, e quello di destinazione che si occupa anche della consegna. In realtà, si possono porre delle esigenze diverse, a causa della struttura della rete nel punto di partenza e nel punto di destinazione. Per rendere l'idea, si possono indicare i casi seguenti.

205.2 Composizione di un messaggio

Un messaggio di posta elettronica è composto da due parti fondamentali: l'intestazione e il corpo. Quest'ultimo è quella parte che contiene il testo del messaggio, mentre l'intestazione contiene informazioni amministrative di vario genere, compreso l'oggetto (subject). All'interno dell'intestazione, si distingue in particolare la busta o envelope, cioè quelle informazioni amministrative necessarie al trasporto del messaggio; queste appaiono nella parte superiore e si espandono mano a mano che il messaggio attraversa i vari MTA necessari a raggiungere la destinazione.

L'esempio seguente mostra un breve messaggio trasmesso da `pippo@router.brot.dg' a `daniele@dinkel.brot.dg'.

From pippo@router.brot.dg  Mon Jun  8 21:53:16 1998
Return-Path: <pippo@router.brot.dg>
Received: from router.brot.dg (pippo@router.brot.dg [192.168.1.254])
	by dinkel.brot.dg (8.8.7/8.8.7) with ESMTP id VAA00615
	for <daniele@dinkel.brot.dg>; Mon, 8 Jun 1998 21:53:15 +0200
From: pippo@router.brot.dg
Received: (from pippo@localhost)
	by router.brot.dg (8.8.7/8.8.7) id AAA00384
	for daniele@dinkel.brot.dg; Tue, 9 Jun 1998 00:00:09 +0200
Date: Tue, 9 Jun 1998 00:00:09 +0200
Message-Id: <199806082200.AAA00384@router.brot.dg>
To: daniele@dinkel.brot.dg
Subject: Una vita che non ci si sente :-)

Ciao Daniele!
Quanto tempo che non ci si sente.
Fai un cenno se possibile :-)

Pippo

Per distinguere la conclusione dell'intestazione dall'inizio del corpo, si utilizza una riga vuota. Nell'esempio, L'oggetto è l'ultimo elemento dell'intestazione, quindi appare una riga vuota di separazione e finalmente inizia il testo del messaggio.

L'intestazione è composta da record separati dal codice di interruzione di riga. Ognuno di questi record, definisce l'informazione contenuta in un campo nominato all'inizio del record stesso, precisamente nella prima colonna del testo. Questi campi (field) terminano necessariamente con il carattere due punti (`:'), seguito da uno spazio, e il resto del record descrive il loro contenuto. Un record può continuare su più righe; la continuazione viene segnalata da un carattere di tabulazione orizzontale, <HT>, all'inizio della riga che continua il record interrotto in quella precedente (si osservino a questo proposito i campi `Received:' dell'esempio).

Il programma usato come MUA genera l'intestazione necessaria a iniziare la trasmissione del messaggio. In particolare, sono fondamentali i campi seguenti.

Oltre ai campi già visti, ne possono essere aggiunti altri, a seconda delle esigenze o dell'impostazione del programma utilizzato come MUA.

Per una convenzione ormai consolidata, il primo record dell'intestazione di un messaggio di posta elettronica inizia con la parola chiave `From' seguita immediatamente da uno spazio. Questo record è diverso da quello che definisce il campo `From:' (cioè quello che termina con i due punti), e per distinguerlo da quest'ultimo, viene spesso indicato come `From_', per sottolineare il fatto che non appaiono i due punti prima dello spazio.

La presenza di questo campo un po' anomalo, fa sì che quando si scrive un messaggio, nel corpo non possa apparire la parola `From' scritta in questo modo e a partire dalla prima colonna. Convenzionalmente, se ne esiste la necessità, viene aggiunto il carattere `>' davanti a questa (`>From'). Il problema si pone essenzialmente quando si vuole incorporare un messaggio di posta elettronica nel corpo di un nuovo messaggio; il programma che si usa per comporre il testo dovrebbe provvedere da solo a correggere la riga in cui appare il record `From_'.

I vari MTA che si occupano di trasferire e consegnare il messaggio a destinazione sono responsabili dell'aggiunta dei campi `Received:'. Questi vengono aggiunti a ogni passaggio, dal basso verso l'alto, e servono a tenere traccia degli spostamenti che il messaggio ha dovuto subire.

205.2.1 Tracciamento di un messaggio

I vari campi `Received:' utilizzati per tenere traccia degli spostamenti di un messaggio di posta elettronica permettono di ricostruirne il percorso. Nell'esempio mostrato in precedenza, venivano utilizzati solo due MTA.

  1. Il primo campo `Received:' partendo dal basso rappresenta il primo MTA che è stato interpellato.

    Received: (from pippo@localhost)
    	by router.brot.dg (8.8.7/8.8.7) id AAA00384
    	for daniele@dinkel.brot.dg; Tue, 9 Jun 1998 00:00:09 +0200
    

    Trattandosi dello stesso nodo da cui è stato inviato il messaggio, appare solo l'informazione dell'MTA, `by router.brot.dg', e la destinazione, `for daniele@dinkel.brot.dg'.

  2. Il secondo campo `Received:' viene aggiunto dal secondo MTA interpellato, che in questo caso è anche l'ultimo.

    Received: from router.brot.dg (pippo@router.brot.dg [192.168.1.254])
    	by dinkel.brot.dg (8.8.7/8.8.7) with ESMTP id VAA00615
    	for <daniele@dinkel.brot.dg>; Mon, 8 Jun 1998 21:53:15 +0200
    

    L'MTA provvede prima a identificare l'origine, ovvero l'MTA che gli ha trasmesso il messaggio, attraverso l'indicazione `from router.brot.dg', e quindi identifica se stesso attraverso l'indicazione `by dinkel.brot.dg'.

I vari record `Received:' possono essere più o meno ricchi di informazioni, e questo dipende dall'MTA che li genera. In particolare, l'indicazione della data permette eventualmente di comprendere in che punto la trasmissione del messaggio è stata ritardata, e la presenza dell'identificativo `id', può permettere di ricercare informazioni su una trasmissione particolare all'interno di registrazioni eventuali.

Alcuni MTA, per motivi di sicurezza, verificano l'origine della trasmissione attraverso il sistema DNS e includono il nome e l'indirizzo IP così ottenuto tra parentesi. Nell'esempio mostrato, il secondo MTA ha indicato `from router.brot.dg (pippo@router.brot.dg [192.168.1.254])'.

205.3 Messaggi contraffatti e punto di iniezione

La posta elettronica è stato il primo problema della comunicazione nella rete. Così, gli standard che si sono ottenuti e i programmi a disposizione sono potentissimi dal punto di vista delle possibilità che vengono offerte. Ciò, assieme al fatto che la trasmissione dei messaggi di posta elettronica è un'operazione gratuita per il mittente, ha favorito chi usa la posta elettronica per «offendere»: sia attraverso la propaganda indesiderata, sia attraverso altre forme più maliziose.

Non è l'intenzione di questo documento la classificazione dei vari tipi di offesa che si possono subire attraverso la posta elettronica, e nemmeno insegnare a usare queste tecniche. La conoscenza dei punti deboli di un MTA è importante per comprendere con quanta serietà vada presa la sua amministrazione, e anche con quanta prudenza vadano mosse delle accuse verso il presunto mittente di un messaggio indesiderato.

Chi utilizza la posta elettronica per attaccare qualcuno, cerca di farlo in modo da non essere identificato. Per questo si avvale normalmente di un MTA di partenza diverso da quello normalmente competente per la sua rete di origine (solitamente il proprio ISP). Oltre a tutto, di solito l'attacco consiste nell'invio di un messaggio a una grande quantità di destinatari, per cui, la scelta di un MTA estraneo (e innocente) serve per scaricare su di lui tutto il lavoro di distribuzione (relay). Il «lavoro» di ogni ipotetico aggressore sta quindi nella ricerca di un MTA che si lasci manovrare e nella composizione di un messaggio con un'intestazione fasulla che lasci intendere che il messaggio è già transitato da un'altra origine (che può esistere effettivamente o meno).

A parte il problema derivato dal fatto che la configurazione degli MTA è difficile, e spesso capita che qualcosa sfugga cosicché l'MTA si trova a permettere accessi indesiderabili, lo standard SMTP è tale per cui l'MTA che riceve un messaggio deve accettare le informazioni che gli vengono fornite riguardo ai punti di transito precedenti (i vari campi `Received:' già esistenti). Quando i campi `Received:' sono stati costruiti ad arte, si parla anche di forging, e l'MTA dal quale ha origine effettivamente la trasmissione è il cosiddetto punto di iniezione.

L'esempio seguente mostra un messaggio di questo tipo, in cui l'origine, `hotmail.com', si è dimostrata fasulla. Probabilmente, il punto di iniezione è stato `cnn.Princeton.EDU', ma questo non può essere stabilito in modo sicuro.

X-POP3-Rcpt: daniele@tv
Return-Path: <seeingclearly40@hotmail.com>
Received: from outbound.Princeton.EDU (outbound.Princeton.EDU [128.112.128.88])
          by tv.calion.com (8.8.4/8.8.4) with ESMTP
          id HAA02209 for <daniele@tv.shineline.it>;
          Tue, 9 Jun 1998 07:12:59 +0200
Received: from IDENT-NOT-QUERIED@Princeton.EDU (port 4578 [128.112.128.81])
	by outbound.Princeton.EDU with SMTP
	id <542087-18714>;
	Tue, 9 Jun 1998 00:48:58 -0400
Received: from cnn.Princeton.EDU by Princeton.EDU (5.65b/2.139/princeton)
        id AA09882; Tue, 9 Jun 98 00:17:18 -0400
Received: from hotmail.com by cnn.Princeton.EDU (SMI-8.6/SMI-SVR4)
        id AAA12040; Tue, 9 Jun 1998 00:17:13 -0400
Message-Id: <199806090417.AAA12040@cnn.Princeton.EDU>
Date:   Mon, 08 Jun 98 11:09:01 EST
From: "Dreambuilders" <seeingclearly40@hotmail.com>
To: Friend@public.com
Subject: Real Business

HOW WOULD YOU LIKE TO BE PAID LIKE THIS?

*How about if you received compensation on 12 months Business Volume for
every transaction in your entire organization and this made it possible for
you to earn over $14000.00 US in your first month ?

* How about if you were paid daily, weekly, and monthly ?...
* How about if you could do business everywhere in the world and be paid in
US dollars ?
* What if your only out of pocket expense was a $10 processing fee to get
started...

* Would you want to evaluate a business like that ?

If so  reply with "real business" in subject box to foureal25@hotmail.com

205.4 Identificazione della destinazione

In precedenza, in questo capitolo, si è accennato al meccanismo di trasferimento dei messaggi tra diversi MTA. L'MTA di origine, o comunque quello utilizzato come distributore di origine (relay), deve identificare l'MTA più adatto a ricevere il messaggio per ottenere la consegna di questo all'utente destinatario. Generalmente, il problema si riduce alla trasformazione del nome di dominio dell'indirizzo di posta elettronica del destinatario in un numero IP, e nel tentativo successivo di contattare tale nodo con la speranza di trovare un MTA pronto a rispondere.

La realtà è spesso più complessa, e può darsi benissimo che l'MTA competente per ricevere la posta elettronica di un certo utente sia un nodo diverso da quello che appare nell'indirizzo di posta elettronica. Per pubblicizzare questo fatto nella rete si utilizzano i record `MX' nella configurazione dei DNS. L'esempio seguente mostra un caso descritto meglio nel capitolo 93 in cui si stabilisce che, per consegnare messaggi di posta elettronica nel dominio `brot.dg', è competente il servente `dinkel.brot.dg'.

brot.dg.	IN	MX	10 dinkel.brot.dg.

205.5 Misure di sicurezza

Le misure di sicurezza fondamentali attraverso cui si cerca di evitare l'uso improprio di un MTA sono essenzialmente di due tipi: l'identificazione del sistema da cui proviene la richiesta di inoltro di un messaggio, attraverso il DNS, e il rifiuto dei messaggi che sono originati da un dominio estraneo e sono diretti anche a un dominio estraneo.

La prima delle due misure si concretizza nell'indicazione tra parentesi del nome di dominio e del numero IP del nodo chiamante nel campo `Received:'. Nell'esempio visto in precedenza, l'MTA del nodo `dinkel.brot.dg' ha verificato l'indirizzo di chi lo ha contattato (`router.brot.dg').

Received: from router.brot.dg (pippo@router.brot.dg [192.168.1.254])
                                     ^^^^^^^^^^^^^^  ^^^^^^^^^^^^^
	by dinkel.brot.dg (8.8.7/8.8.7) with ESMTP id VAA00615
	for <daniele@dinkel.brot.dg>; Mon, 8 Jun 1998 21:53:15 +0200

La seconda misura si avvale generalmente del servizio di risoluzione dei nomi (record `MX'), attraverso il quale si può determinare quale sia il dominio di competenza per il recapito dei messaggi, stabilendo così che i messaggi provenienti dall'esterno che non siano diretti al proprio dominio di competenza, non possono essere accettati.

La maggior parte degli MTA sono (o dovrebbero essere) configurati in questo modo. Questo dovrebbe spiegare il motivo per cui è quasi impossibile inviare messaggi di posta elettronica in una rete locale se prima non si attiva un servizio DNS.

205.6 Referente per l'amministrazione del servizio

L'amministratore di un servizio di distribuzione di posta elettronica deve essere raggiungibile attraverso dei nominativi convenzionali. Fondamentalmente si tratta di `postmaster@<dominio>'. Ultimamente, a causa della crescente invadenza di chi utilizza la posta elettronica in modo fraudolento, è diventato comune l'utilizzo dell'indirizzo `abuse@<dominio>' per identificare la persona competente nei confronti di possibili abusi originati dal servizio di sua competenza.

Naturalmente, tali indirizzi sono generalmente degli alias attraverso cui i messaggi possono essere rinivati al recapito dell'utente che incorpora effettivamente tali competenze.

205.7 Scelta dell'MTA

Nei sistemi Unix, così come in GNU/Linux, la scelta standard del sistema di gestione dei messaggi di posta elettronica è Sendmail, e a questo pacchetto dovrebbe orientarsi l'utente inesperto. Ci si può prendere il lusso di cambiare sistema solo se si conosce bene il problema, e soprattutto le implicazioni rispetto agli altri programmi che hanno qualcosa a che fare con il sistema di invio dei messaggi.

Le difficoltà che derivano dalla scelta di utilizzare qualcosa di diverso da Sendmail possono essere affrontate se ci sono dei buoni motivi. Di solito si abbandona Sendmail a causa della sua storica carenza nei confronti della sicurezza. Con il tempo, Sendmail potrebbe diventare un pacchetto solido e affidabile, ma per il momento, la continua scoperta di nuovi problemi di sicurezza dà a questo sistema una pessima reputazione.

Nella scelta del sostituto di Sendmail si pongono di fronte tre scelte comuni: Smail, Exim e Qmail. I primi due hanno una buona compatibilità con le convenzioni introdotte da Sendmail, mentre l'ultimo punta tutto sulla sicurezza abbandonando quasi tutte le tradizioni precedenti.

205.8 Scelta del servente SMTP per l'elaboratore personale

Quando si deve gestire un solo elaboratore con un solo utente umano, connesso a una rete che fornisce qualche servizio come nel caso di un collegamento con un ISP, ovvero un fornitore di accesso a Internet, si rischia di avere un'idea distorta del problema della posta elettronica.

Si ipotizza una situazione del tipo seguente: è stato ottenuto un accesso a una rete, grande o piccola che sia, con una casella postale collocata presso un nodo di quella rete e con la possibilità di utilizzare un servente SMTP per l'invio della posta elettronica. La connessione a questa rete può essere continua, o discontinua.

In questa situazione, l'elaboratore che viene inserito in tale rete non ha alcun bisogno di gestire un servente SMTP locale, e nemmeno di un sistema di consegna dei messaggi. È sufficiente un programma MUA che per l'invio dei messaggi sia in grado di servirsi direttamente del servente SMTP offerto dalla rete a cui ci si collega, e quindi un programma per il prelievo dei messaggi giunti presso la casella postale remota (protocollo POP2, POP3, o IMAP).

A parte la semplicità dell'approccio, il vantaggio di sfruttare un servente SMTP esterno al proprio elaboratore locale, sta nel fatto che in tal modo è il servente SMTP esterno a preoccuparsi di duplicare il messaggio tra tutti i destinatari (se ne è stato indicato più di uno), e inoltre, è lui che provvede a ritentare gli invii se necessario. Utilizzando per questo un servente SMTP locale, si otterrebbe un maggior carico nel collegamento tra l'elaboratore locale e la rete esterna, e inoltre, non sarebbe possibile interrompere tale comunicazione finché i messaggi trasmessi non risultano recapitati alla destinazione.

Nel caso si possa essere certi di avere una connessione stabile alla rete esterna in questione, se si è ottenuto anche un numero IP statico e quindi un nome di dominio per il proprio nodo, può essere conveniente decidere di mantenere sempre acceso il proprio elaboratore e ricevere direttamente lì la posta. Per questo, occorre attivare un servente SMTP locale che poi provveda alla consegna dei messaggi ricevuti. In pratica serve un MTA completo. In questa situazione, l'elaboratore può avere anche più utenti, e quindi può gestire più caselle postali. Tuttavia, se si dispone sempre di un servente SMTP esterno, è ancora conveniente il suo utilizzo per l'invio dei messaggi.

Nel momento in cui non si tratta più di un semplice elaboratore da collegare a una rete esterna, ma si tratta di tutta una rete locale, il problema cambia aspetto, evidentemente. Ma questo verrà trattato più avanti.

205.9 Pratica manuale con i protocolli

È importante avere un minimo di dimestichezza con i protocolli utilizzati per la gestione della posta elettronica. Oltre all'aspetto puramente didattico, il loro utilizzo manuale attraverso Telnet, può aiutare a verificare la configurazione di un servente SMTP, oppure di manovrare all'interno di una propria casella postale remota.

In queste sezioni vengono mostrati solo i comandi elementari che si possono utilizzare con il protocollo SMTP e POP3.

205.9.1 SMTP via Telnet

È già stato mostrato in precedenza un esempio di connessione con un servizio SMTP allo scopo di inviare manualmente un messaggio. Quell'esempio viene mostrato nuovamente a vantaggio del lettore.

telnet roggen.brot.dg smtp[Invio]

Trying 192.168.1.2...
Connected to roggen.brot.dg.
Escape character is '^]'.
220 roggen.brot.dg ESMTP Sendmail 8.8.5/8.8.5; Thu, 11 Sep 1997 19:58:15 +0200

HELO brot.dg[Invio]

250 roggen.brot.dg Hello dinkel.brot.dg [192.168.1.1], pleased to meet you

MAIL From: <daniele@dinkel.brot.dg>[Invio]

250 <daniele@dinkel.brot.dg>... Sender ok

RCPT to: <toni@dinkel.brot.dg>[Invio]

250 <toni@dinkel.brot.dg>... Recipient ok

DATA[Invio]

354 Enter mail, end with "." on a line by itself

Subject: Saluti.[Invio]

Ciao Antonio,[Invio]

come stai?[Invio]

Io sto bene e mi piacerebbe risentirti.[Invio]

Saluti,[Invio]

Daniele[Invio]

.[Invio]

250 TAA02951 Message accepted for delivery

QUIT[Invio]

221 dinkel.brot.dg closing connection
Connection closed by foreign host.

L'esempio mostra tutto quello che serve fare per inviare un messaggio. I comandi `HELO', `MAIL', `RCPT' e `DATA', vanno inseriti rispettando questa sequenza, e la loro sintassi dovrebbe essere evidente dall'esempio.

Un problema importante che si incontra quando si configura il proprio servizio SMTP è quello del filtro rispetto al relay, cioè all'attività di ritrasmissione dei messaggi. Solitamente si consente il relay senza alcuna limitazione ai messaggi provenienti dai nodi della propria rete locale, mentre lo si impedisce quando il messaggio è di origine esterna a tale rete e in più la stessa destinazione è esterna alla rete locale. Il concetto si esprime facilmente a parole, ma la configurazione del servizio SMTP potrebbe essere complessa, e si può rischiare di tagliare fuori dal servizio proprio alcuni nodi che invece dovrebbero poterlo utilizzare. L'esempio seguente mostra uno di questi casi di cattiva configurazione, e da questo si intende quanto sia utile l'utilizzo manuale del protocollo SMTP per controllare queste situazioni.

telnet dinkel.brot.dg smtp[Invio]

Dal nodo `roggen.brot.dg' si vuole inviare un messaggio al nodo `weizen.brot.dg', utilizzando per questo il servente `dinkel.brot.dg', il quale era inteso dovesse fare da relay, almeno per la rete locale `brot.dg'.

Trying 192.168.1.1...
Connected to dinkel.brot.dg.
Escape character is '^]'.
220 roggen.brot.dg ESMTP Exim 1.90 #1 Wed, 4 Nov 1998 09:47:05 +0100

HELO brot.dg[Invio]

250 dinkel.brot.dg Hello daniele at roggen.brot.dg [192.168.1.2]

MAIL From: daniele@roggen.brot.dg[Invio]

250 <daniele@roggen.brot.dg> is syntactically correct

RCPT to: tizio@weizen.brot.dg[Invio]

550 relaying to <tizio@weizen.brot.dg> prohibited by administrator

Come si può vedere, qualcosa non va: il servente ha accettato l'origine, ma da quell'origine non accetta la destinazione.

QUIT[Invio]

221 roggen.brot.dg closing connection

205.9.2 POP3 via Telnet

Anche l'utilizzo manuale del protocollo POP3 può essere utile. Il problema si pone normalmente quando la propria casella postale remota è stata riempita in maniera abnorme da un aggressore. Se si dispone di un collegamento troppo lento, è meglio evitare di scaricare tutta la posta, mentre sarebbe opportuno eliminare direttamente i messaggi che sembrano essere inutili.

L'esempio seguente serve a capire in che modo è possibile visionare la situazione della propria casella postale remota, e come è possibile intervenire per eliminare i messaggi indesiderati.

telnet dinkel.brot.dg pop-3[Invio]

Trying 192.168.1.1...
Connected to dinkel.brot.dg.
Escape character is '^]'.
+OK POP3 dinkel.brot.dg v4.47 server ready

La prima cosa richiesta è l'inserimento del nominativo-utente, e subito dopo la password.

USER tizio[Invio]

+OK User name accepted, password please

PASS tazza[Invio]

Dopo l'indicazione della password, il servizio POP3 indica quanti messaggi sono presenti. In questo caso solo due.

+OK Mailbox open, 2 messages

Il comando `LIST' consente di avere un elenco dei messaggi con a fianco la loro dimensione in byte. Ciò può essere utile per individuare messaggi «bomba», e l'indizio potrebbe essere dato dalla dimensione esageratamente grande di un messaggio o dal ripetersi di messaggi con la stessa identica dimensione.

LIST[Invio]

+OK Mailbox scan listing follows
1 520
2 498
.

In questo caso, i messaggi sembrano proprio innocui. Eventualmente, se si vede il ripetersi di un messaggio breve, si può controllarne il contenuto, con il comando `RETR'.

RETR 2[Invio]

Viene letto il secondo messaggio.

+OK 498 octets
Return-path: <daniele@dinkel.brot.dg>
Envelope-to: daniele@dinkel.brot.dg
Delivery-date: Wed, 4 Nov 1998 10:06:30 +0100
Received: from daniele by dinkel.brot.dg with local (Exim 1.90 #1)
	for daniele@dinkel.brot.dg
	id 0zayta-00009R-00; Wed, 4 Nov 1998 10:06:30 +0100
To: daniele@dinkel.brot.dg
Subject: SPAM
Message-Id: <E0zayta-00009R-00@dinkel.brot.dg>
From: daniele@dinkel.brot.dg
Date: Wed, 4 Nov 1998 10:06:30 +0100
Status:   

questo e` un messaggio SPAM.
.

La dimensione del messaggio comprende tutto ciò che lo compone, compresa la riga iniziale in cui si informa che questa è di 498 ottetti (gruppi di 8 bit), ovvero byte.

Per cancellare un messaggio, si può utilizzare il comando `DELE', seguito dal numero corrispondente.

DELE 2[Invio]

+OK Message deleted

Per concludere si utilizza il comando `QUIT'.

QUIT[Invio]

+OK Sayonara

205.10 Riferimenti

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]