550 5.7.54 con il connettore giusto: arrivava in IPv6

Un applicativo doveva spedire posta verso l’esterno passando da Exchange. Il connettore di ricezione dedicato era stato creato, gli intervalli di indirizzi erano quelli giusti, il diritto di relay era stato concesso. Il messaggio veniva rifiutato.

550 5.7.54 Unable to relay recipient in non-accepted domain

Rileggere la configurazione del connettore non serviva a niente, perché la configurazione del connettore era corretta. Il problema era che quella connessione non stava arrivando su quel connettore.

Il registro di protocollo dice da dove arrivi

I registri di protocollo SMTP non sono attivi per abitudine, ma sono l’unico posto in cui Exchange dichiara quale connettore ha accettato una connessione e da quale indirizzo l’ha vista arrivare. Attivarli e rileggere ha chiuso la questione in una riga.

LAB-MBX01\Default Frontend LAB-MBX01,...,[fe80::51f1:d32e:f1c2:2fab%4]:25,...

Due informazioni, entrambe inattese.

Il connettore che aveva accettato la connessione era Default Frontend, non quello dedicato all’applicativo. E l’indirizzo di origine era fe80::, cioè IPv6 link-local: l’indirizzo che ogni scheda di rete si dà da sola, senza che nessuno lo configuri.

Perché il connettore giusto non veniva scelto

Il connettore dedicato era in ascolto su 0.0.0.0:25, con intervalli remoti espressi in IPv4. 0.0.0.0 significa «tutti gli indirizzi IPv4 di questa macchina» — non significa «tutti gli indirizzi». Una connessione IPv6 non può corrispondergli, in nessun caso.

Default Frontend, invece, è in ascolto anche su [::]:25. Quando arriva una connessione IPv6, è l’unico candidato rimasto, e Exchange gliela assegna. A quel punto il rifiuto è corretto: Default Frontend non concede il relay a chi non è autenticato, ed è giusto così. Se lo concedesse, il server sarebbe un relay aperto.

Il sistema non stava sbagliando. Stava applicando alla lettera una regola scritta per un altro connettore.

I due rimedi, e quale scegliere

Collegarsi per indirizzo IPv4. L’applicativo punta all’indirizzo numerico invece che al nome. Elimina il problema alla radice e non tocca la configurazione di Exchange, ma perde la risoluzione dei nomi: se il server cambia indirizzo, l’applicativo va rimesso a mano.

Aggiungere fe80::/64 agli intervalli remoti del connettore.

Set-ReceiveConnector "smtp-app-lab" -RemoteIPRanges @{add="fe80::/64"}

Mantiene il nome e fa corrispondere anche le connessioni IPv6. È la scelta più pulita, a una condizione: che il connettore sia effettivamente in ascolto anche su [::]:25, altrimenti si è aggiunto un intervallo a un connettore che comunque non verrà mai selezionato.

Verificare, non dare per scontato:

Get-ReceiveConnector "smtp-app-lab" | Select-Object Bindings, RemoteIPRanges

La scoperta collaterale

Nello stesso registro, poche righe più in là, c’era un secondo rifiuto che non si stava cercando.

Inbound authentication failed as we reject well-known account
authentication for CONTOSO\Administrator
535 5.7.3 Authentication unsuccessful

Exchange rifiuta per principio l’autenticazione SMTP degli account noti — Administrator in testa — a prescindere dalla password. Non è una politica configurata: è un comportamento del prodotto.

È lo stesso 535 5.7.3 che si incontra in produzione quando qualcuno prova a far spedire un applicativo con le credenziali dell’amministratore «tanto per provare». Non funzionerà mai, e la ragione non è la password. È anche il motivo strutturale per cui gli applicativi vanno dotati di account di servizio dedicati: non è solo igiene, è l’unica cosa che Exchange accetta.

Le tre lezioni

Prima di rileggere la configurazione, verifica che sia quella in uso. Ore spese a controllare un connettore corretto sono ore in cui la domanda giusta — quale connettore ha risposto? — non era ancora stata posta.

0.0.0.0 non vuol dire «tutto». Vuol dire «tutto l’IPv4». Ogni regola scritta in IPv4 ha un buco esattamente della forma dell’IPv6, e quel buco si apre da solo il giorno in cui un client decide di preferirlo.

Un rifiuto può essere il sistema che funziona. Default Frontend ha fatto il suo lavoro. Il guasto era a monte, nell’instradamento della connessione, e cercarlo nel componente che protestava significava cercarlo nel posto sbagliato.

Laboratorio costruito con il supporto di Ilie.