Exchange: consentire solo mittenti esterni selezionati a una lista di distribuzione
È possibile configurare una lista di distribuzione in Exchange affinché possa essere raggiunta solo da determinati mittenti esterni. Due metodi con PowerShell: restrizione di recapito con contatti e-mail o regola di trasporto. Inoltre, i limiti della verifica del mittente e come DMARC li colma.
Per impostazione predefinita, una lista di distribuzione in Exchange accetta messaggi solo da mittenti autenticati, ovvero interni. Se anche un partner, un fornitore o un cliente deve poter raggiungere la lista senza aprirla all’intera Internet, esistono due possibilità: una restrizione di recapito sul gruppo stesso oppure una regola di trasporto. Entrambe funzionano in Exchange Server 2016, 2019 e Subscription Edition.
Situazione iniziale: RequireSenderAuthenticationEnabled
La proprietà RequireSenderAuthenticationEnabled controlla se un gruppo accetta messaggi esterni. Se è impostata su $true (impostazione predefinita per i nuovi gruppi di distribuzione), Exchange rifiuta ogni messaggio proveniente da un mittente non autenticato. Entrambe le varianti seguenti presuppongono quindi che questo controllo sia disattivato:
Set-DistributionGroup -Identity "Projektteam" -RequireSenderAuthenticationEnabled $false
Senza ulteriori restrizioni, dopo questo passaggio qualsiasi mittente esterno può scrivere alla lista. La limitazione a singoli mittenti segue nel passaggio successivo, idealmente nella stessa finestra di manutenzione.
Variante 1: restrizione di recapito con contatti e-mail
L’elenco dei mittenti consentiti (AcceptMessagesOnlyFromSendersOrMembers) accetta solo oggetti della directory locale: cassette postali, utenti di posta elettronica, contatti e-mail e gruppi. Non è possibile inserire un semplice indirizzo SMTP. Per ogni mittente esterno è quindi necessario creare un contatto e-mail. Per evitare che il contatto compaia nell’elenco indirizzi globale, nasconderlo:
$kontakt = @{
Name = "Extern Max Muster"
ExternalEmailAddress = "max.muster@partner.example"
OrganizationalUnit = "example.local/Kontakte/Extern"
}
New-MailContact @kontakt
Set-MailContact -Identity "Extern Max Muster" -HiddenFromAddressListsEnabled $true
Successivamente, aggiungere il contatto come mittente consentito. La hashtable con Add integra l’elenco esistente anziché sovrascriverlo:
$erlaubt = @{ Add = "Extern Max Muster", "Extern Anna Beispiel" }
Set-DistributionGroup -Identity "Projektteam" -AcceptMessagesOnlyFromSendersOrMembers $erlaubt
Non appena questo elenco contiene almeno una voce, Exchange rifiuta tutti gli altri mittenti, compresi quelli interni. Se i collaboratori devono continuare a poter scrivere alla lista, aggiungere anche un gruppo adeguato, ad esempio il gruppo di distribuzione stesso (in tal caso tutti i membri possono inviare) oppure un gruppo con tutti i collaboratori. I mittenti rifiutati ricevono un rapporto di mancato recapito con lo stato 5.7.1.
Per verificare lo stato attuale:
Get-DistributionGroup -Identity "Projektteam" |
Format-List Name, RequireSenderAuthenticationEnabled,
AcceptMessagesOnlyFrom, AcceptMessagesOnlyFromDLMembers
AcceptMessagesOnlyFromSendersOrMembers è un parametro collettivo: Exchange distribuisce le voci tra le proprietà AcceptMessagesOnlyFrom (singoli mittenti) e AcceptMessagesOnlyFromDLMembers (gruppi). Per questo motivo la query mostra queste due proprietà. La stessa impostazione è disponibile nell’Exchange Admin Center, nelle proprietà del gruppo, in Gestione recapito (Delivery management).
Questa variante è adatta se vengono aggiunti solo pochi mittenti esterni e l’elenco dei mittenti consentiti deve essere visibile direttamente nell’oggetto gruppo. Lo svantaggio è l’onere di gestione: ogni nuovo mittente richiede un contatto in Active Directory.
Variante 2: regola di trasporto senza contatti
Se internamente tutti devono poter continuare a scrivere alla lista e devono essere limitati solo i mittenti esterni, una regola di trasporto è più semplice. Non richiede contatti e può essere applicata anche a interi domini. Anche in questo caso RequireSenderAuthenticationEnabled deve essere impostato su $false.
$regel = @{
Name = "Projektteam: nur freigegebene externe Absender"
SentTo = "projektteam@example.com"
FromScope = "NotInOrganization"
ExceptIfFromAddressMatchesPatterns = '^max\.muster@partner\.example$',
'@lieferant\.example$'
RejectMessageReasonText = "Sie sind nicht berechtigt, an diese Adresse zu senden."
RejectMessageEnhancedStatusCode = "5.7.1"
}
New-TransportRule @regel
Senza l’ancoraggio con ^ e $, un modello come max\.muster@partner\.example corrisponderebbe anche a max.muster@partner.example.net. Aggiungere nuovi mittenti con Set-TransportRule e l’elenco completo ed esteso dei modelli; il parametro sostituisce l’elenco esistente.
Limite di entrambe le varianti: l’indirizzo del mittente è falsificabile
Entrambe le varianti verificano solo l’indirizzo del mittente. Exchange non stabilisce se il messaggio provenga effettivamente dal partner autorizzato. Chi conosce l’indirizzo di un mittente autorizzato può falsificarlo e raggiungere così la lista. Per una lista con partecipanti interni, questo costituisce un punto di ingresso per il phishing, che per di più appare provenire da un indirizzo noto.
SPF, DKIM e DMARC colmano questa lacuna. Se il dominio del partner dispone di una policy DMARC con p=reject o p=quarantine e il gateway di posta applica tale policy, i messaggi falsificati di quel dominio non raggiungono nemmeno Exchange. Per domini senza policy DMARC o con p=none questa protezione manca.
Se il gateway scrive il risultato della verifica nell’header Authentication-Results, una seconda regola di trasporto può inoltre rifiutare mittenti autorizzati se DMARC non è superato:
$regel = @{
Name = "Projektteam: freigegebene Absender nur mit DMARC pass"
SentTo = "projektteam@example.com"
FromScope = "NotInOrganization"
FromAddressMatchesPatterns = '^max\.muster@partner\.example$',
'@lieferant\.example$'
ExceptIfHeaderMatchesMessageHeader = "Authentication-Results"
ExceptIfHeaderMatchesPatterns = 'dmarc=pass'
RejectMessageReasonText = "Absender konnte nicht verifiziert werden."
RejectMessageEnhancedStatusCode = "5.7.1"
}
New-TransportRule @regel
Questa regola funziona in modo affidabile solo se il gateway rimuove o sovrascrive gli header Authentication-Results in arrivo da Internet. Altrimenti, un mittente può fornire autonomamente l’header con dmarc=pass. La documentazione del gateway descrive quali header imposta e se rimuove gli header esterni; Exchange stesso non valuta DMARC.
Quale variante scegliere
La restrizione di recapito con contatti è adatta a liste con una cerchia fissa e ristretta di mittenti esterni e, se desiderato, limita anche i mittenti interni. La regola di trasporto è adatta quando tutti possono inviare internamente, quando occorre autorizzare interi domini partner o quando non devono essere creati contatti in Active Directory. Indipendentemente dalla variante, verificare la policy DMARC per ogni dominio autorizzato e documentare chi gestisce l’elenco dei mittenti consentiti.
Commenti
I commenti vengono caricati da GitHub / Giscus.