Cosa succede se non limito le connessioni SMTP in ingresso?
dobbiamo distinguere 2 diversi casi:
- ricevo un numero di richieste minore della mia capacità di assorbimento
- ricevo un numero di richieste superiore alla mia capacità di assorbimento.
nel primo caso le implicazioni sono ovviamente minori e quindi, analizzeremo cosa succede nel secondo.
la prima domanda da porsi è: perché saturo le mie connessioni SMTP disponibili in ingresso?
la risposta è evidentemente legata al fatto che che vengono generate moltissime connessioni da molteplici fonti esterne.
una delle prime cose che occorre capire del protocollo SMTP e le implementazioni che ne danno i vari servizi postali è che tutti cercano di scodare le proprie mail nella maniera più efficace ed efficiente possibile.
questo viene di solito ottenuto con due meccanismi:
- cercare di aprire il maggior numero di sessioni SMTP concorrenti possibile
- cercare di mettere sul canale SMTP aperto il maggior numero di messaggi possibile.
In altre parole quando un mailserver A cerca di spedire posta a mailserver B viene effettuata una transazione tra i due servers in cui A cerca di allocarsi il maggior numero di risorse possibili su B ed è compito di B porre dei limiti a A.
Il server A cerca di aprire una connessione con il server B attraverso una connessione TCP tramite il classico Handshake a 3 vie e dichiara di voler comunicare tramite il protocollo SMTP.
B risponde generalmente accettando le connessioni TCP e preparandosi a ricevere le connessioni SMTP in ingresso. Il comportamento dal lato SMTP di B non è in realtà dettato da una contrattazione a livello di protocollo SMTP ma alla configurazione della MTA di B.
A in realtà cerca di aprire il maggior numero di connessioni SMTP possibili, su ogni connessione cerca di inviare il massimo numero di messaggi che è possibile inviare. Ancora una volta questo comportamento è dettato dalla configurazione della MTA di A.
Se A supera la capacità ricettiva di B, B smette di accettare ulteriori connessioni.
Il limite raggiunto da B può essere fisico, non avendo più disponibilità di gestire connessioni, o amministrativo.
Questo scenario si ripete anche per tutti gli altri eventuali server presenti su internet che cercano di mandare posta a B.
Vanno considerati in questo scenario 2 aspetti fondamentali:
- il server B non ha capacità illimitata di ricezione
- ogni sessione SMTP dura il tempo necessario a mandare il numero di messaggi previsti dal sender, Questo tempo varia a seconda della quantita’ di dati e può essere di breve durata ma anche di diverse decine di secondi.
Questi due fattori concorrono a ridurre la disponibilità di B a ricevere connessioni da sorgenti multiple, quando infatti viene raggiunto il limite di connessioni disponibili viene rifiutata la connessione agli altri emettitori.
Questo comporta a sua volta che gli emettitori che si vedono rifiutato l’accesso al canale SMTP iniziano ad eseguire retry per cercare di ottenere accesso al canale.
Dal momento che il comportamento degli emettitori in termini di numero di connessioni e messaggi inviati per connessione è imprevedibile, occorre cercare di gestire le politiche di accesso al server B in maniera oculata.
Lo scopo delle policy da implementare deve essere quello di consentire al maggior numero di mittenti la possibilità di connettersi, per raggiungere questo scopo occorre innanzi tutto essere sicuri che nessuno dei mittenti possa impadronirsi di tutte le connessioni concorrenti gestibili dal server di posta.
in altre parola ha senso, dal punto amministrativo imporre un limite per connessione che sia
Numero connessioni x Host << numero connessioni effettive disponibili.
In questo modo si evita che una sorgente saturi la destinazione a scapito di altri emettitori.
Va posta anche attenzione al numero di messaggi ammissibili sul canale SMTP.
qui le considerazioni sono più delicate a causa del comportamento estremamente variabile delle MTA su internet.
Alcune implementazioni cercano di mandare sul canale SMTP aperto il maggior numero di messaggi possibile, altre preferiscono puntare sul numero di connessioni concorrenti mandando un solo messaggio per connessione.
La chiave qui ancora una volta e ricordarsi che il canale SMTP viene utilizzato per tutta la durata della trasmissione dei messaggi, il che significa che limitare il numero di messaggi inviati porta alla chiusura anticipata del canale SMTP e quindi alla sua disponibilità ad una altro emettitore.
E’ buona norma quindi cercare di limitare il numero di connessioni per Host in ingresso per rendere e risorse disponibili per gli altri emettitori. Un errore che si compie nel disegno di soluzioni SMTP è spesso quello di considerare che chi ha maggior posta da inviare ha bisogno di una maggiore priorità. Paradossalmente è vero proprio il contrario, chi manda poca posta dovrebbe avere una maggiore priorità di chi ne manda molta, in termini di disservizio il rallentamento è più sensibile rispetto chi manda 4 messaggi che chi ne manda 4000. Del resto questo è lo stesso approccio che si usa nella distribuzione dei task elaborativi nei calcolatori condivisi, dove generalmente i grossi processi elaborativi hanno priorità più bassa rispetto a quelli brevi.
Quali sono i limiti da imporre per host è ovviamente oggetto di discussione, ogni amministratore di rete può fare le proprie considerazioni in merito tenendo però presente almeno due fattori:
- la effettiva capacità ricettiva della propria piattaforma
- il livello di esposizione ai flussi SMTP
Volendo dare indicazioni di massima si può partire, per effettuare delle valutazioni, dalla saturazione delle connessioni in ingresso per poi decidere come agire.
Cosi se la piattaforma accetta, ad esempio, 200 connessioni concorrenti per la saturazione è sensato imporre limiti del tipo 20 connessioni concorrenti per Host. (1 decimo).
Lo scopo, ancora una volta, è garantire un flusso distribuito di una risorsa che non è illimitata.
Se guardiamo quello che fanno i grandi provider di posta come Google, Yahoo o MSNLive vediamo che loro adottano sui loro sistemi questo tipo di strategia in maniera abbastanza severa:
Yahoo.com – 8 concurrent connections, 15 recipients
Hotmail.com – 10 concurrent connections, 25 recipients
Gmail.com – 20 concurrent connections, 100 recipients
Queste limitazioni sono indiscriminate (x host base) e quindi non legate ad uno specifico emettitore e rappresentano il massimo numero di connessioni e messaggi per connessione che un mail server può fare per mandare posta a questi provider.
Si noti come queste limitazioni non implicano poi nella esperienza normale una riduzione della capacità ricettiva di questi providers, ma, al contrario, una migliore distribuzione di questa capacità e quindi, in ultima analisi, un miglior servizio.
NOTA A:
Questo discorso inerente alle limitazioni in ingresso va accoppiato con un generale discorso della gestione della banda e delle connessioni ottenibile, ad esempio, da servizi di reputation. Il primo non esclude l’altro, ma entrambi concorrono ad un corretto flusso di gestione della messaggistica.
NOTA B:
Effettuare un reject di una connessione comporta comportamenti diversi a seconda che si effettui la operazione a livello SMTP o TCP. In entrambi i casi vi sono Pro e Contro ed occorre valutare cosa sia meglio ottenere.
Fare un Reject a livello TCP comporta sicuramente il retry della connessione dello stack TCP, questo avviene generalmente indipendentemente dalla natura della connessione TCP. questo blocco è pero solitamente mal digerito dai Mailservers e i loro amministratori che vedono sommarsi agli errori SMTP sempre presenti anche una serie di errori lato network.
Va pero osservato che il blocco a Livello TCP avviene in maniera molto rapida e non impegna tutto lo stack del protocollo, il risultato è che questa operazione risulta molto leggera ed efficace soprattutto in ambienti dove la decisione venga presa appoggiandosi come discriminante a valori di IP reputation.
In un ambienti in cui si usi ESA quindi può avere senso effettuare il taglio a livello TCP per valori di reputation molto bassi in modo da liberare risorse SMTPin maniera piu veloce.
Il Reject a livello SMTP invece è più impegnativo in termini di risorse ma riduce sensibilmente il numero di retry nel caso il taglio sia effettuato nei confronti di macchine compromesse. I demoni che inviano spam infatti difficilmente fanno retry in queste condizioni. Ha senso quindi effettuare tale reject a questo livello per valori di reputation su cui si applica del throttling (o limitazione di banda) alla connessione.
Sulla piattaforma ESA è possibili anche impostare il Delayed Reject che avviene a Sessione SMTP completamente attivata ed interviene dopo che è stato mandato il “mail from” da parte del mittente.
Questo riduce ulteriormente , statisticamente parlando, il numero di retry da parte delle piattaforme emittenti ma ha come contropartita un maggior impegno della piattaforma di ricezione. Va detto però che in questa maniera si possono ottenere statistiche più puntuali sul numero di mail rigettate perché non legate alla assunzione del moltiplicatore per le connessioni SMTP rigettate (la assunzione solitamente è 3 mail per connessione SMTP rigettata).
Nel complesso una politica sugli ESA che mescoli connessioni rifiutate a livello SMTP col delayed reject e rifiutate a livello TCP risulta piu performante di una basata sul semplice reject SMTP.
)
sarebbe stata scorporata da tempo per garantire almeno un regime di concorrenza reale (chiedete a Bell) …
