Titolo: Configurazione di un dominio di posta elettronica conforme agli standard RFC822 e RFC1123 Autore: E. Calia C. Comella D. Vannozzi Data: 03-10-1994 Riferimento: itanetdoc10.txt -------------------------------------------------------------------- Configurazione di un dominio di posta elettronica conforme agli standard RFC822 e RFC1123 (postmaster@dominio.registrato) Edoardo Calia - Cosimo Comella - Daniele Vannozzi 1. INTRODUZIONE Nei documenti RFC822 ed RFC1123 viene richiesto che in ogni dominio di posta elettronica e su ogni singolo host che si intendano utilizzare almeno per la ricezione di posta SMTP sia possibile effettuare una corretta consegna di messaggi indirizzati a "postmaster@dominio" (o "postmaster@host.dominio"), dando cosi' la possibilita' di inviare a questo indirizzo delle richieste inerenti la gestione del servizio di e-mail. Da RFC822: "This standard specifies a single, reserved mailbox address (local-part) which is to be valid at each site. Mail sent to that address is to be routed to a person responsible for the site's mail system or to a person with responsibi- lity for general site operation. The name of the reserved local-part address is: Postmaster so that "Postmaster@domain" is required to be valid. Note: This reserved local-part must be matched without sensitivity to alpha- betic case, so that "POSTMASTER", "Postmaster", and even "poStmASteR" is to be accepted. Da RFC1123: "... A host that supports a receiver-SMTP MUST support the reserved mailbox "Postmaster" ...." Inoltre, RFC1648 (Postmaster Convention for X.400 operations) estende lo stesso concetto a tutti i domini X.400 per i quali esista un mapping (secondo le norme specificate in RFC1327) verso il formato RFC822. Tali domini sono infatti indistinguibili dai domini RFC822 da parte di utenti finali che operano su Internet. RFC1648 costituisce pertanto un passo nella direzione della interoperabilita' dei due principali mondi della messaggistica elettronica. Il presente documento si propone di fornire delle indicazioni per configurare il software di rete in un dominio Internet registrato affinche' questo sia conforme ai requisiti fin qui esposti; nello stesso tempo queste indicazioni potranno rivelarsi utili per il funzionamento, piu' in generale, del servizio di posta elettronica. Le azioni che l'amministratore del dominio dovra' svolgere si articolano in due fasi. Nella prima fase bisognera' garantire la raggiungibilita' per posta elettronica del dominio, cioe' la possibilita' per il generico mittente di specificare il nome del dominio o il nome di un host esteso col nome del dominio come parte destra di un indirizzo destinatario di posta elettronica in formato RFC822. In questa fase si dovra' operare sul software utilizzato per integrare il dominio in questione nel DNS. Nella seconda fase si dovra' garantire che il particolare nome "postmaster" sia correttamente utilizzabile come parte sinistra di un indirizzo destinatario, supponendo la correttezza della parte destra. Questa seconda fase comportera' una opportuna configurazione dell'host o degli host deputati al servizio di e-mail nel dominio, con particolare attenzione alla configurazione del software di posta elettronica responsabile dell'accettazione dei messaggi tramite SMTP (Simple Mail Transfer Protocol). 2. USO DEL DNS PER LA RAGGIUNGIBILITA' DEL DOMINIO Uno dei prerequisiti per la messa in atto delle indicazioni contenute in questo documento e' che il dominio che si vuole configurare sia gia' integrato nel DNS (cosa che dovrebbe considerarsi gia' acquisita per i domini registrati), ovvero che sia servito da uno o piu' nameserver su cui sia attiva una implementazione del DNS. La gestione dei nameserver potra' avvenire all'interno del dominio oppure esser delegata a organizzazioni esterne. In quest'ultimo caso spettera' al gestore del nameserver ospitante garantire il rispetto delle norme (vedi RFC974 "Mail routing and the domain system"). La piu' diffusa implementazione del DNS in Internet, e in particolare su sistemi Unix, e' il BIND (Berkeley Internet Name Domain), a cui faremo riferimento nel seguito. Il BIND e' basato su un processo (named o in.named) che, guidato da opportuni file di dati che costituiscono il suo "database", si occupa di rispondere alle query associando a nomi simbolici gli indirizzi IP o altri attributi. In particolare, nella risoluzione diretta degli indirizzi si associa a un nome in "domain style" la lista di IP address (uno o piu') ad esso corrispondenti; nella risoluzione inversa a partire da un IP address fornisce il corrispondente nome simbolico. Risoluzione diretta e inversa sono realizzate inserendo nei database di BIND dei record di tipo "A" (address) e di tipo "PTR" (pointer), rispettivamente. In aggiunta a questi record (e insieme ad altri tipi di record) e' possibile inserire nei database di BIND dei record di tipo "MX" (Mail eXchanger), il cui uso e' estremamente importante ai fini della posta elettronica. 2.1 Il BIND e i record MX I record MX servono a instradare i messaggi diretti ad un certo e-mail (di host o di dominio) verso un host che viene detto MX (Mail eXchanger) host. Il record host1 IN MX 10 host2 nel database di BIND per un particolare dominio dirotta tutta la posta indirizzata a user@host1 verso user@host2, in cui "user" e' il nome di un generico destinatario. Al nome "host2" dovra' corrispondere nel DNS un record "A" o almeno un record "CNAME"; cio' significa che il nome verso cui si dirotta la posta deve essere o il nome canonico di un host (preferibilmente) oppure un suo alias: in definitiva deve trattarsi di un'entita' dotata di IP address. Non e' consentito effettuare redirezioni concatenate come in host1 IN MX 10 host2 host2 IN MX 10 host3 visto che in questo caso host2 non e' riconducibile a un IP address. Le entita' che fanno uso dei record MX e dell'informazione da questi veicolata sono principalmente i sistemi software responsabili del trattamento della posta (Mail Transport Agent), che hanno bisogno di individuare, tramite apposite query al DNS, uno o piu' host a cui connettersi per la trasmissione dei messaggi in SMTP verso un certo dominio destinatario. Potendo il Mail eXchanger essere piu' di uno, ad ognuno di essi deve essere associata una preferenza cioe' un numero di priorita' per il quale vale la regola: numero piu' basso preferenza maggiore. ========= Esempio 1 ========= Il name server del dominio POLITO.IT potrebbe avere per l'host CENTAURO.POLITO.IT i seguenti MX record: hostname class type pref mail exchanger CENTAURO.POLITO.IT IN MX 10 CENTAURO.POLITO.IT. IN MX 20 POL88B.POLITO.IT. IN MX 30 POL88A.POLITO.IT. In tal modo la query per un MX host relativo a CENTAURO.POLITO.IT restituisce come mail exchanger a priorita' piu' alta lo stesso CENTAURO.POLITO.IT (cui dovra' corrispondere anche un record di tipo "A" e che, se attivo, ricevera' la e-mail direttamente). Nel caso in cui l'host CENTAURO.POLITO.IT risultasse non raggiungibile il messaggio verrebbe inviato a uno degli altri host specificati, tenendo conto del valore del "preference" (pref). L'MX host che ricevera' la posta potra' farsi carico della consegna, in qualsivoglia forma e protocollo, all'utente destinatario oppure terra' la posta nella sua coda fino a che un Mail eXchanger con priorita' piu' alta non sia raggiungibile. ========= Esempio 2 ========= hostname class type pref mail exchanger UTOVRM.IT IN MX 10 INFNGW.INFN.IT. IN MX 20 CNAF-GW.INFN.IT. Qui il nome a sinistra e' nome di un dominio registrato ma non e' nome di un host perche' non ha record "A" ad esso associati, non e' quindi provvisto di IP address; il solo nome di dominio non consentirebbe in questo caso una facile identificazione dell'host a cui consegnare la posta con una connessione SMTP. Gli MX record indicano due host esterni al dominio con cui tentare la connessione SMTP, con priorita' maggiore a quello con numero di preferenza minore. Entrambi gli host indicati dovranno essere in grado di accettare la posta diretta al dominio UTOVRM.IT e consegnarla al destinatario secondo modalita' concordate (es: con protocolli Decnet). Gli scopi della redirezione della posta tramite gli MX record, come parzialmente evidenziato dagli esempi, sono molteplici: - instradare messaggi diretti a destinazioni particolari, anche non connesse direttamente ad Internet, verso il gateway opportuno; in tal modo anche nomi di host sprovvisti di SMTP (o globalmente di TCP/IP) potranno essere usati come parte destra di indirizzi RFC822, purche' siano in grado di ricevere in qualche modo la posta dagli MX host designati; - "nascondere" i nomi dei singoli host dietro un nome di dominio (site hiding); - fornire una pluralita' di scelte dell'host partner della connessione SMTP in modo da ovviare alla indisponibilita' (per guasti o per sovraccarico o irrangiungibilita') di un host in particolare; in questo modo si accresce la probabilita' di corretta consegna del messaggio in SMTP. 2.2 Cosa fare in assenza di MX host Puo' accadere che il DNS non restituisca alcun MX host per un qualche indirizzo in "domain style": in tal caso si prevede che il mittente tenti una connessione diretta in SMTP con l'host corrispondente alla parte destra dell'indirizzo destinazione. Se l'indirizzo destinazione non e' dotato di IP address non sara' allora possibile consegnare la posta elettronica a nessun host. D'altra parte puo' accadere anche che alcuni sistemi siano dotati di software per posta elettronica con ridotte capacita' di interrogazione del DNS e in particolare incapace di utilizzare gli MX record, mentre lo stesso software sara' capace di recuperare gli IP address (record A). E' questo il caso di piccoli sistemi (PC, Macintosh,...) connessi in rete con TCP/IP ma anche di moderne workstation Unix distribuite con MTA spesso non aggiornati (vecchie versioni del sendmail "no-MX" di SunOS e di IBM/AIX). Si tratta di situazioni in palese violazione di standard accettati, laddove RFC1123 ("Host Requirements") prevede che debbano essere onorati gli MX record. Tuttavia in questi casi l'abbinamento (nel nameserver autoritativo per il dominio destinazione) di un record "A" ad un certo nome rendera' quel nome utilizzabile ai fini della posta elettronica SMTP, garantendo un indirizzo IP a cui connettersi nel caso non esistano o non siano utilizzabili gli MX record. ========= Esempio 3 ========= Nel database di BIND sul nameserver autoritativo per il dominio INFO.UTOVRM.IT si trovano i record: INFO.UTOVRM.IT IN A 160.80.27.59 IN MX 10 SOLARIS.INFO.UTOVRM.IT. IN MX 20 KERBEROS.INFO.UTOVRM.IT. SOLARIS.INFO.UTOVRM.IT. IN A 160.80.27.59 KERBEROS.INFO.UTOVRM.IT. IN A 160.80.27.58 Il nameserver restituira' allora come MX record per INFO.UTOVRM.IT gli host "SOLARIS" e "KERBEROS", dotati di record "A"; per quei mittenti incapaci di interrogare correttamente il DNS vi e' stato aggiunto un record "A" (abbinato al nome del dominio) che rendera' questo raggiungibile con SMTP anche dai siti con MTA non conformi agli standard (nell'esempio l'IP address scelto per il nome del dominio coincide, non a caso, con l'host "puntato" nel record MX con maggiore preferenza). 3. RAGGIUNGIBILITA' DEL POSTMASTER PRESSO UN DOMINIO Per consentire questa operazione nel modo piu' semplice, assumendo che siano state seguite le procedure indicate nella sezione 2, volte a far arrivare correttamente le mail indirizzate a "postmaster@host" o postmaster@ su alcuni opportuni host, e' necessario che su tali host esista l'utente (username o login-name, a secondo della terminologia specifica del sistema operativo in uso) "postmaster". Tuttavia non sempre questa soluzione e' la piu' indicata, perche' prevede la creazione di un account che il responsabile della posta elettronica dovrebbe esplicitamente utilizzare, possibilmente con frequenza giornaliera, per controllare eventuali richieste di informazioni, segnalazioni da parte di utenti remoti o messaggi di errore generati dal software di posta elettronica. Per ovviare all'inconveniente del login esplicito sull'account "postmaster" e' possibile stabilire una redirezione della posta in arrivo a "postmaster" verso un altro valido indirizzo locale sfruttando le capacita' di "forwarding" o di "aliasing" presenti in molti sistemi operativi e software per e-mail. L'aliasing consente di redirigere i messaggi da una mailbox all'altra, similmente a quanto fanno gli MX record che redirigono i messaggi da un host all'altro. Il meccanismo di aliasing viene chiamato in causa ogni volta che il sistema SMTP ricevente riconosca il comando "RCPT TO:" seguito da un indirizzo la cui parte destra venga accettata come "locale". In questo caso il ricevente dovra' verificare se la parte sinistra dell'indirizzo corrisponda al nome di un utente oppure ad un alias. E' anche necessario che il dominio sia riconosciuto come "locale" dall'host (spesso e' quello "puntato" dal record MX con priorita' piu elevata) che si fa' carico della consegna finale della mail all'utente. 4. CONCLUSIONI I gestori di domini registrati sono esortati a configurare il software di rete in modo conforme alle indicazioni di questo documento, individuando gli host che possano svolgere funzioni di Mail eXchanger per il dominio. Su questi host dovra' essere attivata la mailbox "postmaster" in uno dei modi suggeriti al punto 3 (semplice creazione dell'utente postmaster, creazione dell'utente con forward ad un altro utente reale, aliasing del nome postmaster in altro nome di utente reale). Rimangono esclusi dalla trattazione di questo documento i casi in cui uno stesso MX host debba accettare posta perpiu' domini e per ognuno di questi si vogliano creare delle mailbox "postmaster" distinte (questo problema e' risolvibile ma richiede una trattazione piu' approfondita).