[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
Quando si gestisce un elaboratore che offre servizi di rete, 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 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.
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.
|
Figura 154.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.
L'MTA utilizzato nell'origine si avvale di uno smarthost, ovvero un altro MTA, collocato in una posizione conveniente della rete, che si occupa di smistare i messaggi. Ciò è utile quando l'MTA di origine è collocato in una posizione della rete per cui esiste un solo percorso per raggiungere la rete esterna: quando un messaggio è inviato a più di un destinatario è conveniente trasmetterlo una volta sola attraverso questo tratto di rete, lasciando che sia l'MTA esterno a provvedere alla duplicazione dei messaggi per i vari destinatari. Lo smarthost svolge quindi l'attività di relè, o di scambio.
L'MTA di destinazione è il punto di ingresso a una rete privata, nella quale vengono poi usati altri MTA per la consegna effettiva dei messaggi.
L'MTA di destinazione è solo il punto di arrivo di un alias (da quel punto riprende l'invio del messaggio all'indirizzo vero dell'utente).
Un messaggio di posta elettronica è composto da due parti fondamentali: l'intestazione e il corpo. Il corpo è 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; 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.
| Campo | Descrizione |
| Date: | Contiene la data di invio del messaggio. |
| Message-Id: | Contiene una stringa generata automaticamente, in modo da essere unica per il messaggio. In un certo senso, serve a dare un'impronta al messaggio che permette di distinguerlo e di farvi riferimento. |
| From: | Contiene le informazioni sul mittente del messaggio; generalmente si tratta dell'indirizzo di posta elettronica e probabilmente anche il suo nome reale. |
| To: | Contiene l'indirizzo di posta elettronica del destinatario. |
| Subject: | L'oggetto del messaggio. |
Oltre ai campi già visti, ne possono essere aggiunti altri, a seconda delle esigenze o dell'impostazione del programma utilizzato come MUA.
| Campo | Descrizione |
| Reply-To: | Permette di indicare un indirizzo al quale si desidera siano inviate le risposte. |
| Organization: | Permette di definire l'organizzazione proprietaria della macchina da cui ha origine il messaggio di posta elettronica. |
| X-...: | I campi che iniziano per X- sono ammessi, senza essere definiti. In pratica, vengono utilizzati per scopi vari, accordati tra le parti. |
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), tanto che per distinguerlo 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, allo scopo di tenere traccia degli spostamenti che il messaggio ha dovuto subire.
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.
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.
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; 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; inoltre, 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]).
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 (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. 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, per cui capita spesso 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 contraffatti 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
|
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 (relè), 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, per poi tentare 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 122 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. |
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).
|
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 spesso è impossibile inviare messaggi di posta elettronica in una rete locale se prima non si attiva un servizio DNS.
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.
Nei sistemi Unix, così come in quelli GNU, la scelta tradizionale del sistema di gestione dei messaggi di posta elettronica è Sendmail. Ci si può prendere il lusso di cambiare sistema solo se si conosce bene il problema e le implicazioni rispetto agli altri programmi che hanno qualcosa a che fare con il sistema di invio dei messaggi.
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.
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 bisogno (almeno in teoria) 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, 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); 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; 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 è stato 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, gestendo così 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.
È 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 un cliente 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.
È già stato mostrato in precedenza un esempio di connessione con un servizio SMTP allo scopo di inviare manualmente un messaggio. Lo stesso 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 relè, cioè all'attività di ritrasmissione dei messaggi. Solitamente si consente di fare il relè senza alcuna limitazione per i 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 un esempio di cattiva configurazione e da questo si intende quanto sia utile l'utilizzo manuale del protocollo SMTP per controllare tali 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 relè, 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
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 parola d'ordine.
USER tizio[Invio]
+OK User name accepted, password please
PASS tazza[Invio]
Dopo l'indicazione della parola d'ordine, 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», dove 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
Olaf Kirch, NAG, The Linux Network Administrators' Guide
Doug Muth, The SPAM-L FAQ
daniele @ swlibero.orgDovrebbe essere possibile fare riferimento a questa pagina anche con il nome gestione_della_posta_elettronica_in_generale.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]