Exchange Queue & AProtezione dei protocolli di posta elettronica, posta indesiderata misteriosa e altro

Nino Bilic and Scott Landry

Questo articolo si basa su una versione provvisoria di Windows Server 2008. Tutte le informazioni riportate sono soggette a modifica.

D Desidero utilizzare il protocollo SMTP protetto. Come posso configurare Exchange Server in modo che ascolti il traffico SMTP sulla porta 465?

R Purtroppo si tratta di un obiettivo irrealizzabile. Certo è possibile configurare qualsiasi server virtuale SMTP o connettore di ricezione in modo che ascolti sulla porta 465, ma il supporto del protocollo SMTP protetto (SMTPS, Simple Mail Tranfer Protocol Secure) resta escluso.

Perché? Bene, facciamo qualche passo indietro. Esistono due tipi di SSL: esplicito e implicito. Inizialmente, le connessioni SSL erano nella maggior parte implicite, cioè veniva utilizzata una porta dedicata per le comunicazioni basate su questo protocollo. Ad esempio, il traffico HTTP viene ascoltato per impostazione predefinita sulla porta 80, mentre il traffico HTTPS (HTTP con SSL) viene ascoltato sulla la porta 443. Alcuni anni fa, la community di Internet decise che non era necessaria una porta dedicata per SSL. È per questa ragione che è nato il protocollo SSL esplicito.

Netscape aveva già scelto la porta 465 come porta SMTPS, ma Exchange Server non disponeva di alcuna funzionalità SSL in SMTP. Tuttavia, il team di Exchange si rese conto del notevole vantaggio del protocollo SSL esplicito, ovvero la possibilità di essere utilizzato sia dai client che dai server, e decise di utilizzarlo per SMTP.

Nel caso di SMTP, il protocollo SSL esplicito utilizza il comando STARTTLS ESMTP per segnalare che il socket esistente sta per essere protetto. Anche la maggior parte degli altri fornitori di client e server SMTP ha scelto di implementare il comando STARTTLS, per cui non si avvertiva particolarmente l'esigenza di supportare la porta 465, che in ogni caso non era uno standard Internet ufficiale.

Fino a oggi, nessuna versione di Exchange Server supporta il protocollo SSL implicito per SMTP. La configurazione di un server virtuale SMTP o connettore di ricezione di Exchange per l'ascolto sulla porta 465 non modifica questo stato di cose. Pertanto, è necessario utilizzare un client che supporti STARTTLS sulla porta 25. Se non è possibile utilizzare tale porta, la scelta logica ricade sulla porta 587, che è la porta standard per gli invii SMTP client. Non sono molti i client moderni che non supportano STARTTLS sulla porta 25, quindi non è stato necessario aggiungere supporto per il protocollo SSL implicito.

Tra l'altro, i protocolli POP3 e IMAP4 in Exchange hanno sempre supportato SSL implicito. In Exchange Server 2007, però, è disponibile ora il supporto per SSL esplicito anche per questi due protocolli. Poiché, tuttavia, sono ancora pochi i client compatibili con questo standard più recente, il protocollo SSL implicito sarà ancora in circolazione per un bel po'.

D Mi trovo improvvisamente a dover gestire una grande quantità di posta in coda per più domini, eppure nessuno dei miei utenti ha inviato messaggi. Cosa sta succedendo e come posso evitarlo?

R Purtroppo si tratta di fenomeno frequente. In effetti, chiunque abbia un server su Internet può incorrere in questo problema. Fondamentalmente, sono due le cause possibili. È probabile che inavvertitamente sia stato aperto il server per l'inoltro (vedere support.microsoft.com/kb/304897). Naturalmente, è difficile che ciò accada. Tra l'altro, gli inoltri aperti sono stati disabilitati per impostazione predefinita a partire da Exchange Server 2000. Pertanto è più probabile che si tratti di un messaggio di posta elettronica indesiderato con rapporto di mancato recapito. Nel processo di invio di posta elettronica commerciale indesiderata, gli spammer spesso inoltrano i messaggi a indirizzi non esistenti presso il dominio preso di mira. Il server tenta di informare lo spammer che gli utenti non esistono, ma naturalmente l'indirizzo del mittente è stato falsificato. È possibile che lo spammer stia effettuando lo spoofing di un indirizzo non valido (nel qual caso il rapporto NDR rimane in sospeso per un certo periodo di tempo finché non scade) oppure è possibile che stia tentando di fare in modo che il server della vittima invii messaggi indesiderati a un altro dominio per conto suo, sotto forma di allegati del rapporto NDR generato dal server.

Per risolvere il problema, è possibile disabilitare i rapporti NDR. In tal caso, tuttavia, se un utente legittimo dovesse inavvertitamente digitare un indirizzo in modo errato, il server non lo informerebbe mai che il suo messaggio non è giunto a destinazione e potrebbero andare perdute informazioni importanti. Ecco quindi una soluzione migliore.

Per prima cosa, accertarsi che il server non sia aperto per l'inoltro (so che è ovvio, ma devo dirlo). Quindi, attivare il filtro posta indesiderata, ad esempio il filtro messaggi intelligente, il filtro contenuto di Exchange Server 2007 o la funzionalità di blocco degli indirizzi in tempo reale. Questo filtro può essere attivato sia nel ruolo Trasporto Edge che nel ruolo Trasporto Hub, purché venga fatto quanto prima perché l'attacco potrebbe estendere il suo raggio d'azione fino a investire oltre il 90% del volume dei messaggi e certo non è il caso di tenere i server occupati con una tale mole di posta indesiderata.

Infine, è necessario abilitare il filtro destinatario sul primo server Exchange che accetta posta nell'ambiente in uso. Ciò consentirà al server di rifiutare un messaggio prima che entri nella rete. Nel caso di errori nella digitazione di indirizzi legittimi, verrà comunque generato un rapporto NDR, ma in questo caso verrà generato dal server del mittente.

D Fino a qualche tempo fa, i due server di cui disponevo eseguivano rispettivamente Exchange Server 2000 ed Exchange Server 2003 ed entrambi inviavano correttamente messaggi in Internet. Dopo aver installato Exchange Server 2007, le cassette postali di entrambi i server non sono più in grado di inviare messaggi.

R Questa domanda rivela una scarsa dimestichezza con il concetto di connettori, non insolita per chi è abituato a utilizzare un solo server Exchange. I connettori di Exchange sono oggetti per la configurazione del routing logico che indicano a Exchange dove indirizzare i messaggi di posta elettronica. Quando si introduce Exchange Server 2007 in un'organizzazione esistente, per poter instradare la posta è indispensabile disporre di connettori dei gruppi di routing e di un connettore SMTP.

In questo caso specifico, sono necessari due connettori dei gruppi di routing, uno che va dal gruppo di Exchange Server 2007 a quello di Exchange Server 2003 e l'altro che procede in senso contrario. La configurazione può essere effettuata durante il processo di installazione, ma se ci si è dimenticati o non si è certi di averla eseguita, è possibile controllare utilizzando Exchange Management Shell e correggere il problema con questa shell. Se i due connettori non vengono configurati, non sarà possibile lo scambio di posta tra i server. I messaggi finiranno in code di destinazione irraggiungibili.

Per instradare la posta in Internet occorre invece un unico connettore SMTP, definito anche connettore di invio in Exchange Server 2007. Dovrebbe esserne disponibile uno in Exchange Server 2000 ed Exchange Server 2003, ma forse non ne è stato utilizzato nessuno. Lo spazio degli indirizzi deve essere SMTP:* per tutti i domini ed è possibile specificare l'utilizzo di uno smart host o di un DNS per il recapito della posta. Inoltre, è possibile impostare il server che esegue Exchange Server 2007 o il server precedente in modo che gestisca la posta Internet in uscita oppure creare un connettore in entrambi i gruppi di routing se si desidera che ogni server gestisca la propria posta. È anche possibile crearne uno come parte del processo Edgesync se è stato installato un ruolo del server Trasporto Edge.

Se precedentemente è stato impostato uno smart host sul server virtuale SMTP, adesso è possibile rimuoverlo. Lo smart host infatti deve essere configurato solo sul connettore SMTP, mai sul server virtuale in quanto danneggerebbe il connettore del gruppo di routing.

Va inoltre tenuto presente che la posta elettronica in ingresso è controllata dal record MX o dall'IP verso cui il firewall esegue l'inoltro. Il lavoro di configurazione sul lato di Exchange non è molto, ma questo documento dovrebbe essere d'aiuto in caso di problemi: msexchangeteam.com/archive/2006/11/17/431555.aspx.

D Perché ricevo più rapporti del journal per lo stesso messaggio in Exchange Server 2007?

R L'agente di journaling per il trasporto di Exchange Server 2007 inserirà i messaggi nel journal dopo la classificazione. Sono diverse le ragioni per cui il classificatore biforca un messaggio, ovvero copia il corpo del messaggio e specifica i diversi destinatari delle buste sulle copie. Ecco un esempio: poiché ora l'agente di journaling è in grado di stabilire quali erano i membri di un gruppo di distribuzione al momento dell'invio di un messaggio, la ricezione di più rapporti può verificarsi nel caso di un gruppo di distribuzione nidificato.

Questa maggiore ricchezza di informazioni nella creazione dei rapporti fa sì che si possano ricevere più copie dello stesso messaggio, ciascuna con un rapporto univoco. Non esiste un metodo infallibile per sapere se tutti i rapporti pervenuti riguardano un unico messaggio, tuttavia, se si sta effettuando l'archiviazione della posta, è consigliabile collaborare con il proprio fornitore di servizi di archiviazione per assicurarsi che sia al corrente delle modifiche.

D Non trovo la funzionalità per l'inoltro dei messaggi non risolti all'host in Exchange Server 2007? Che posso fare?

R Deve essersela mangiata il cane.

In verità, la funzionalità in questione non si è mai rivelata particolarmente efficace in situazioni in cui i server Exchange erano più di uno. In ogni caso, in Exchange era disponibile già un altro metodo, di gran lunga più valido, per eseguire la stessa operazione. Nello specifico, tale metodo consente di condividere singoli domini SMTP con altri sistemi. Pertanto, la funzionalità di inoltro dei messaggi non risolti è stata eliminata e il concetto dei domini condivisi è stato ulteriormente sviluppato e semplificato. In Exchange Server 2007, basta accedere a Organizzazione | Trasporto Hub | Domini accettati e modificare il tipo di dominio da Autorevole in Inoltro interno. In effetti, per alcuni ambienti le cose non sono proprio così semplici ed è per questo che stiamo aggiornando parte della documentazione. Ma, nel frattempo, queste indicazioni dovrebbero essere d'aiuto.

D Sto tentando di preparare il dominio radice per l'installazione di Exchange Server 2007. Sul server da cui desidero eseguire tale processo è installato il componente Gestore di sistema di Exchange di Exchange Server 2003 e l'installazione di Exchange Server 2007 ha esito negativo. Qual è il problema?

R In parole povere, l'esecuzione di qualsiasi parte dell'installazione di Exchange Server 2007 su un computer che già dispone di componenti di Exchange Server 2000 o 2003 non è supportata. In questo caso, durante il processo di installazione di Exchange Server 2007 verrà rilevata la presenza del Gestore di sistema di Exchange di Exchange Server 2003, quindi il controllo dei prerequisiti per l'installazione avrà esito negativo e verrà visualizzato il messaggio "Nel computer è già installata una versione precedente di Exchange Server. Eseguire l'installazione di Exchange 2007 da un computer diverso o rimuovere la versione precedente di Exchange Server".

Probabilmente il modo più semplice per risolvere il problema consiste nell'eseguire l'installazione di Exchange Server 2007 da un altro server del dominio radice e nel preparare il dominio a tale scopo. Se ciò non è possibile, sarà necessario disinstallare il componente di Exchange Server 2003 prima di procedere con l'installazione di Exchange Server 2007.

Si ricordi che è possibile utilizzare la versione a 32 bit di Exchange Server 2007 per preparare il dominio, quindi qualsiasi server a 32 bit del dominio radice è idoneo allo scopo. Per ulteriori informazioni in proposito, vedere technet.microsoft.com/library/bb232170.aspx.

Ciò significa, tra l'altro, che non è possibile installare i componenti Gestore di sistema di Exchange di Exchange Server 2003 ed Exchange Management Console di Exchange Server 2007 sullo stesso computer in quanto la coesistenza di strumenti di gestione di Exchange Server 2003 ed Exchange Server 2007 sullo stesso computer non è supportata. Pertanto, se si tenta di installare Exchange Server 2007 su un computer in cui sono già presenti componenti di Exchange Server 2000 o Exchange Server 2003, il processo verrà bloccato.

Infine, si tenga presente che non si deve mai tentare di installare sullo stesso computer prima gli strumenti di gestione di Exchange Server 2007 e successivamente gli strumenti di Exchange Server 2003. Questo tipo di approccio produrrà una configurazione che non è stata testata e potrebbe generare risultati imprevisti durante la gestione dei server. Se si ha la necessità di gestire entrambe le versioni server da un unico computer, è possibile utilizzare un desktop remoto per connettersi a una versione oppure utilizzare un computer virtuale per ospitare una versione differente degli strumenti di gestione in un ambiente isolato.

D Quando sarà possibile finalmente eseguire gli strumenti di gestione di Exchange Server 2007 su una workstation Windows Vista®?

R Il supporto ufficiale per gli strumenti di gestione di Exchange Server 2007 in Windows Vista verrà fornito a partire da Exchange Server 2007 SP1. Un pacchetto contenente gli strumenti di gestione di Exchange Server 2007 SP1 sarà disponibile per il download non appena Exchange Server 2007 SP1 verrà rilasciato.

D Sarà possibile anche eseguire il Gestore di sistema di Exchange di Exchange Server 2003 su Windows Vista o su Windows Server 2008?

R Sfortunatamente no. Gli strumenti di gestione relativi a qualsiasi versione di Exchange Server precedente a Exchange Server 2007 SP1 non saranno supportati né in Windows Vista né in Windows Server 2008. Ciò significa che anche dopo il rilascio di Windows Server 2008, l'installazione del Gestore di sistema di Exchange di Exchange Server 2003 non sarà supportata. La gestione dei server Exchange Server 2003 dovrà essere eseguita da workstation su cui è installato Windows Server 2003 o Windows XP o, in alternativa, sarà possibile utilizzare una connessione desktop remoto da qualsiasi sistema operativo.

D Più server Exchange Server 2003 sono in esecuzione nel mio dominio. Sarà possibile aggiornare i controller di dominio a Windows Server 2008?

R Sì, l'esecuzione di Exchange Server 2003 SP2 in un dominio che dispone di controller di dominio Windows Server 2008 è supportata. Si noti che Exchange Server non può utilizzare server di catalogo globale di sola lettura o controller di dominio di sola lettura Windows Server 2008. Se viene specificato manualmente, a livello di codice, l'utilizzo di questo tipo di server o di controller di dominio da parte di Exchange Server, potrebbe verificarsi un comportamento imprevisto.

Nino Bilic è Supportability Program Manager per Exchange Server. Nel tempo libero si dedica alla scoperta delle meraviglie delle comunicazioni tra server leggendo avidamente tonnellate di tracce Netmon prima di andare a dormire.

Scott Landryè Support Escalation Engineer per Exchange Server. Non viaggia mai senza il suo asciugamano, la sua copia della Guida e il suo fedele telefono Windows Mobile.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.