Capitolo 12. Approfondimenti sul relay della posta via SMTP

Sommario

Il problema del relay
Esempi di configurazione
Configurazione del modulo all'interno di un firewall packet filter che fa NAT
Ricezione della posta

Il problema del relay

Il modulo SMTP è stato concepito per filtrare la posta in base a determinati criteri specificati dall'utente e poi inviarla (routing) verso la destinazione desiderata. Un problema che si può verificare durante questo processo e al quale è necessario prestare la dovuta attenzione, è di evitare utilizzi indesiderati da parte di estranei.

Al fine di evitare che utenti esterni utilizzino il modulo SMTP per spedire messaggi indirizzati ad altri utenti esterni, è necessario configurare correttamente il modulo SMTP. L'utilizzo improprio dei relay di posta (e il modulo SMTP rientra in questa categoria) è il maggior veicolo di diffusione dello spam, dove il mittente cerca di nascondere la propria identità. In tal caso infatti il destinatario finale vede il messaggio provenire dal modulo SMTP e non dal vero mittente. Lo scopo che ci si prefigge nella configurazione del modulo è quello di impedire che faccia da relay in queste circostanze. Per fare ciò occorre configurare correttamente i parametri "Host Locali" e "Relay Domain".

Supponendo di avere un Mail Server interno, devono essere accettati i seguenti messaggi:

  • il messaggio proviene dall'esterno ed è diretto ad uno degli utenti interni al dominio.

  • il messaggio proviene dall'interno ed è diretto o ad uno degli utenti interni al dominio o ad un dominio esterno.

deve essere invece vietata la seguente condizione:

  • il messaggio proviene dall'esterno ed è diretto ad un utente esterno al dominio locale.

Purtroppo a questo occorre aggiungere che il solo dominio di provenienza della mail non è sufficiente a stabilire se il mittente è un utente interno o esterno. Il problema risiede infatti nella struttura stessa del protocollo SMTP che non prevede di autenticare il mittente. Naturalmente in caso di mittente fasullo, una eventuale risposta sarebbe impossibile da consegnare, tuttavia il problema nel caso in oggetto è di stabilire se il mittente può o no mandare il primo messaggio.

Per questa ragione occorre verificare anche ove si trova il server (o il client) che spedisce la mail al modulo SMTP, in particolare se l'indirizzo IP di tale server appartiene o no agli host della rete locale. Una volta definita questa classe di indirizzi, il modulo può stabilire agevolmente se effettuare il relay o no della mail che riceve.

Esempi di configurazione

Verranno presi ora in esame un paio di scenari e verranno dati suggerimenti su come configurare il modulo SMTP.

Negli esempi che seguono viene utilizzata la classe 10.xx.xx.xx come classe di indirizzi privata.

Configurazione del modulo all'interno di un firewall packet filter che fa NAT

Lo scenario si compone delle seguenti macchine:

  • Firewall Packet Filter che fa NAT e inoltra la posta in entrata verso una macchina sulla rete interna

  • eXtensiveControl® su cui è configurato il modulo SMTP per filtrare la posta

  • Sever di posta interno che gestisce le caselle di posta degli utenti e a cui questi si collegano (tipicamente col protocollo POP3) per prelevare la posta.

  • Client sulla rete interna: le macchine degli utenti che si collegano al server di posta per inviare e ricevere la posta.

Si supponga che il firewall abbia indirizzo interno (gateway) 10.1.1.1, eXtensiveControl® abbia indirizzo 10.1.1.2 e il server di posta 10.1.1.3. Tutti i client invece hanno indirizzi 10.1.2.xx, ove xx varia da client a client. Il dominio in cui gli account di posta sono definiti sarà example.com e gli utenti saranno user01, user02, ecc. Un indirizzo di posta valido sarà ad esempio user02@example.com.

Una possibile configurazione in questo caso è la seguente:

Ricezione della posta

  • Il firewall permette la connessione dalla sorgente esterna da cui la posta arriva verso il modulo SMTP di eXtensiveControl®, cioè verso il 10.1.1.2.

  • Il modulo SMTP di eXtensiveControl® avrà configurato come relay domain: example.com e come host locale la classe 10.*. Inoltre, ma questo non fa parte delle regole antirelay, dovrà aver configurato la sezione Route del MTA (vedere la sezione chiamata «Route») per fare il relay di example.com verso il server interno di posta (10.1.1.3) e tutto il resto ("*") verso un server di relay esterno (oppure verso lo stesso server di posta 10.1.1.3 se è quest'ultimo che è preposto a spedire la posta verso il mondo esterno).

  • Il server di posta verrà configurato per ricevere la posta solamente da eXtensiveControl® (quindi 10.1.1.2) in quanto i messaggi provenienti dai client dovranno passare attraverso quest'ultimo (in modo che possano essere all'occorrenza filtrati) prima di uscire verso l'esterno.

  • I client dovranno invece essere configurati con l'impostazione SMTP (outgoing) che punta ad eXtensiveControl® cioè a 10.1.1.2.

Si osservi che quando la posta arriva dall'esterno, il firewall cambia solo l'indirizzo di destinazione (che in questo caso diventa il 10.1.1.2) ma non la sorgente, che figura quindi come esterna. Pertanto eXtensiveControl® accetterà di fare da relay solo per destinatari appartenenti al dominio example.com. Gli utenti interni, provenendo invece dalla classe 10.1.2.xx non avranno problemi a spedire la posta sia ad altri utenti interni sia ad utenti esterni, poiché il mittente ha dominio example.com e indirizzo appartenente all'insieme degli host locali.