AuthMechanism 10 e AuthAs Internal: come Exchange classifica l'invio nell'header

Nell’analisi di casi di spam, spoofing e flusso della posta in ambienti Exchange, sono determinanti tre intestazioni che Exchange aggiunge alla ricezione:

X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthSource: EX01.example.com
X-MS-Exchange-Organization-AuthMechanism: 10

AuthAs registra in quale veste il mittente si è presentato al trasporto. AuthSource indica il server che ha effettuato la valutazione. AuthMechanism documenta il meccanismo con cui è avvenuta l’autenticazione. Insieme determinano se Exchange tratta un messaggio come interno o esterno, e questa classificazione ha conseguenze significative.

Perché la classificazione è importante

AuthAs presenta in pratica due valori: Internal e Anonymous. Un messaggio classificato come Internal viene trattato diversamente dalla posta esterna:

• Le regole di flusso della posta con la condizione «mittente esterno all’organizzazione» non vengono applicate.
• Il messaggio può essere recapitato a gruppi di distribuzione e cassette postali che richiedono mittenti autenticati (RequireSenderAuthenticationEnabled).
• I controlli antispam e antispoofing sono meno severi o vengono omessi; negli ambienti ibridi non viene aggiunto il disclaimer esterno e Outlook non mostra l’avviso «Esterno».
• Il nome visualizzato viene risolto dalla rubrica e l’e-mail appare ai destinatari come posta interna.

Proprio per questo la domanda «AuthAs Internal o Anonymous?» deve essere all’inizio di ogni analisi dell’header: consente di chiarire perché un’e-mail di spoofing evidente abbia superato il filtro antispam o perché una regola di flusso della posta non sia mai stata attivata.

I valori di AuthMechanism

Microsoft non documenta completamente in pubblico la codifica di AuthMechanism. Due valori sono rilevanti e ben documentati per la risoluzione dei problemi:

Altri valori compaiono negli header, ma non dispongono di riferimenti ufficiali. Nella pratica basta la distinzione: 04 indica un’autenticazione Exchange effettiva, 10 indica attendibilità basata sulla configurazione del connettore.

Cosa significa davvero Externally Secured

L’opzione ExternalAuthoritative su un Receive Connector comunica a Exchange che la protezione di questa connessione è gestita da qualcun altro, ad esempio un firewall, un segmento di rete dedicato o IPsec. Exchange non effettua quindi ulteriori controlli, ma tratta ogni invio tramite questo connettore come autenticato e interno, incluso il diritto di utilizzare qualsiasi indirizzo mittente interno.

È pensata per pochi scenari, ad esempio un server applicativo completamente attendibile nel proprio data center. Diventa problematica quando il connettore punta a un gateway di posta a monte o a un filtro antispam nella DMZ, attraverso il quale arriva anche posta da Internet. Dopo l’invio, ogni e-mail esterna presenta quindi:

X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 10

Le conseguenze: le e-mail esterne sono considerate interne, le regole di flusso della posta per mittenti esterni non vengono applicate, la protezione dallo spoofing per il proprio dominio è inefficace e chiunque raggiunga il gateway può recapitare ai destinatari, usando indirizzi mittente interni, messaggi che in realtà richiedono mittenti autenticati.

Individuare i connettori interessati

La Exchange Management Shell mostra quali Receive Connector sono configurati con ExternalAuthoritative:

Get-ReceiveConnector | Where-Object {
  $_.AuthMechanism -match "ExternalAuthoritative"
} | Format-Table Identity, RemoteIPRanges, AuthMechanism, PermissionGroups

Per ogni risultato, verificare quali RemoteIPRanges sono configurati e se i sistemi a valle necessitano effettivamente di questa attendibilità. Un gateway che deve soltanto inoltrare e-mail non ne ha bisogno.

L’alternativa per gli scenari di relay

Se un sistema deve soltanto effettuare relay anonimo tramite Exchange (stampanti, applicazioni, monitoraggio), un connettore relay anonimo è la soluzione più pulita: invio anonimo più il diritto di recapitare a destinatari arbitrari, ma senza la classificazione Internal.

New-ReceiveConnector -Name "Anonymous Relay" -TransportRole FrontendTransport `
  -RemoteIPRanges 192.0.2.10 -Bindings 0.0.0.0:25 -Usage Custom -PermissionGroups AnonymousUsers

Get-ReceiveConnector "EX01\Anonymous Relay" | Add-ADPermission `
  -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

Le e-mail inviate tramite questo connettore rimangono AuthAs: Anonymous, passano attraverso i controlli normali e non possono simulare mittenti interni. ExternalAuthoritative resta riservato ai sistemi ai quali si desidera concedere consapevolmente il diritto di usare indirizzi mittente interni.

Leggere gli header nel contesto

Per capire più rapidamente se un messaggio concreto è stato classificato come interno o esterno e da quale percorso è arrivato, è necessario leggere l’header completo: AuthAs, AuthMechanism e AuthSource insieme alla catena Received. L’analizzatore di header delle e-mail su questo sito valuta direttamente nel browser questi campi e evidenzia la classificazione ibrida nel percorso di recapito; l’header non lascia il browser.

L’articolo Interna o esterna? Classificare le e-mail Exchange ibride nell’header tratta come la classificazione venga mantenuta tra Exchange Online e OnPrem negli ambienti ibridi e come riconoscere un’assegnazione errata.