Email Communication Service: il servizio per spedire posta con Azure

Gli Email Communication Services rappresentano la modalità di spedizione di posta elettronica tramite gli Azure Communication Services. Essi non solo costituiscono un mezzo molto versatile per inviare email, ma integrano anche funzionalità di gestione feedback, come il monitoraggio di apertura/click dei link, oppure la gestione delle disiscrizioni.

La struttura delle risorse nel portale Azure inizialmente potrebbe risultare non intuitiva, ma capendola sarà possibile sfruttare alcuni vantaggi, infatti la prima cosa che si nota quando ci si approccia a questo servizio è il fatto che sembra essere separato dal resto degli ACS, presentando un tipo di risorsa dedicato:

Immagine in cui vengono visualizzate le due risorse Azure necessarie per utilizzare gli ECS
 Figura 1 – Screenshot delle due risorse disponibili nell’Azure Marketplace

Tuttavia non dovremo farci ingannare da questa divisione, per raggiungere il nostro obiettivo necessitiamo entrambe le risorse.

Come dominio mittente Azure ne mette a disposizione uno in loro gestione, attivabile con un solo click, opzione molto utile per effettuare dei test nel caso in cui non dovessimo avere l’accesso alla zona DNS, tuttavia i limiti di spedizione imposti sono molto bassi, per tutti i casi di produzione è consigliabile utilizzare un dominio di nostra proprietà.

Autenticazione e sicurezza

In altri articoli di questo blog si è parlato di autenticazione delle fonti di spedizioni tramite i protocolli SPF, DKIM e DMARC, è d’obbligo quindi approfondire la loro implementazione nell’ambito degli ECS. Gli IP pubblici dei server di spedizione sono inclusi nello stesso record SPF che Microsoft fa includere durante la configurazione del dominio su Exchange Online, quindi chi usufruisce di questo servizio, non dovrà effettuare nessuna modifica. Al contrario, per la configurazione del DKIM sarà necessario creare i due record che ci verranno indicati. Per ultimo, ma non meno importante, dovremo determinare se e come implementare il DMARC, se usiamo un dominio su cui è già configurato o un suo sottodominio, non sarà necessario fare nient’altro. Per approfondire il funzionamento di questi protocolli consiglio la lettura di questo articolo.

Una volta autenticata la fonte di spedizione, dovremo assicurarci che chi la utilizza sia effettivamente autorizzato a farlo, in parole povere dobbiamo fare in modo che la nostra risorsa ECS possa venire utilizzata solo per scopi legittimi. Per fare ciò Azure ci consente di usare due metodi: autenticazione tramite segreto condiviso, oppure sfruttando le identità applicative (metodo più moderno, il quale si integra con l’Azure RBAC). É molto importante sapere che l’autorizzazione alla spedizione non viene data tramite una configurazione dell’ECS, ma si dovrà fare riferimento alle pagine dedicate nella risorsa ACS (che sia quella dedicata alle chiavi, o quella del controllo degli accessi). Per semplicità in questo articolo non approfondirò il discorso dei permessi, tuttavia di seguito lascerò i link della documentazione ufficiale.

Modalità di spedizione

Come anticipato nell’introduzione le modalità di spedizione sono diverse, la più versatile è la richiesta HTTPS, la quale però richiede la composizione completa dell’oggetto rappresentante la mail oltre che la gestione dell’autenticazione autenticazione verso l’endpoint di Microsoft.

La seconda modalità, quella più indicata, è l’utilizzo dell’SDK ufficiale, disponibile per diversi linguaggi di programmazione, esso fornisce una serie di classi che ci agevoleranno sia nel processo di autenticazione che in quello di spedizione.

La terza opzione è quella dell’SMTP, in questo caso l’unico modo per autenticare il client è tramite identità applicativa, tuttavia a livello protocollare non si va oltre la basic authentication, che comunque guadagna qualche punto in sicurezza per il fatto che deve essere obbligatoriamente effettuata tramite TLS (porta 587).

Immagine che schematizza le modalità di spedizione delle mail tramite gli ECS, oltre che le opzioni di autenticazione verso quest'ultimi.
Figura 2 – Schema rappresentante le possibilità di autenticazione verso gli ACS

Limitazioni

Purtroppo questo servizio non si adatta a tutte le necessità, presenta alcune limitazioni che lo potrebbero rendere inutilizzabile in alcuni casi.

  • Prima tra tutte risulta essere quella che non permette di spedire più di 100 email all’ora, tale limite non viene inteso per singolo ECS, ma viene calcolato sull’intera sottoscrizione Azure;
  • Non è possibile personalizzare l’indirizzo mittente, esso infatti viene forzato a “DoNotReply@<dominio>”;
  • La funzionalità di tracciamento apertura email e click dei link non è abilitabile di default.

Microsoft però ci informa che è possibile effettuare una richiesta per aumentare il numero di email inviabili, e che tale procedura andrebbe a rimuovere anche gli altri due limiti descritti, ampliando di molto il pubblico che potrebbe usufruire di questo servizio.

Conclusione

Ritengo che gli Email Communication Services siano un servizio molto comodo per la velocità di deployment e la versatilità d’integrazione che offrono senza dimenticarci che sono integrati con Azure RBAC per la gestione dei permessi, tuttavia vedendo le limitazioni iniziali che vengono imposte risulta più idoneo per la spedizione di posta applicativa.

Riferimenti

Autenticazione HTTPS

Inviare posta con l’SDK di ECS

Inviare posta tramite SMTP

Gestire le liste di disiscrizione

Funzionalità di tracciamento apertura e click dei link

Limiti di invio