Vi sottopongo un problema che sto avendo con un cliente che deve mandare PEC da dei server alla fine di transazioni finanziarie.
Il mio cliente ha dei server sulla Google Cloud Platform, che abbiamo scoperto avere un firewall che blocca tutte le connessioni verso porte note SMTP. Ho verificato con loro che lo scopo è evitare che i suoi netblock finiscano nelle black list antispam ed è più che comprensibile. Ho fatto un giro dei siti di tutti gestori PEC elencati sul sito dell’AgID e sembra che tutti accettino connessioni cifrate su porta 465 (il che è un bene) e nessuno abbia metodi alternativi (peccato). Google blocca la 465 e probabilmente non è l’unica cloud che lo fa.
Per ora il mio cliente ha poco traffico e manderà le PEC a mano, ma prima o poi dovremo automatizzare l’invio. Credo che il problema possa diventare più generale mano a mano che la PEC guadagnerà d’importanza nel corso degli anni, quindi perché non pensare ad una soluzione?
Sarebbe sufficiente che i gestori PEC implementino un singolo endpoint HTTPS per l’invio dei messaggi, secondo uno standard sul formato dei dati accettati, altrimenti verrebbe meno l’interoperabilità tra i gestori (è lo scopo di avere un protocollo come SMTP). Non mi faccio illusioni sui tempi per vedere qualcosa del genere in produzione, ma si deve pur iniziare: credo che se implementato possa aiutare le aziende medio piccole, che non hanno budget per svilupparsi soluzioni in proprio o che comunque lo impiegherebbero in modo più proficuo.
Può darsi che non offrire interfacce alternative all’SMTP sia un requisito normativo per i gestori. Ho googlato un po’ e non ho trovato nulla in proposito, ma potrei aver visto male. Ho guardato quali dati debbano essere conservati dai gestori, nel caso ci sia qualcosa impossibile da ricavare se non via SMTP. L’unico candidato è il Message-ID, ma viene generato o dal client o dal primo mail server lungo la strada. Quel mail server sarebbe quello a cui il server HTTPS invia i
dati ricevuti, quindi non è un problema.
Nel caso del mio cliente è possibile che dovremo scrivere un nostro server che da un lato accetti JSON su HTTPS e dall’altro invii la mail. Lo metteremo da qualche provider che non abbia firewall. Il formato che avevo immaginato è una semplificazione di quello di Mandrill documentato a
https://mandrillapp.com/api/docs/messages.JSON.html a cui aggiungerei
login e password da usare nel collegamento al server SMTP. Perché Mandrill? Perché in quel progetto lo stiamo già usando per la mail transazionale, nessuna preferenza particolare.
{
"auth": {"username": "...", "password": "..."},
"message": {
"sender": {"email": "sender@example.com", "name": "Sender Name"}
"recipients": [
{"type": "to", "email": "recipient1@example.com", "name": "Recipient 1 Name"},
{"type": "cc", "email": "recipient2@example.com", "name": "Recipient 2 Name"},
],
"headers": {
"Reply-To": "sender@example.com"
},
"subject": "subject",
"text": "text content",
"html": "<p>html content</p>",
"attachments": [
{
"type": "text/plain",
"name": "file.txt",
"content": "<base 64 encoded>"
}
]
}
}
Potrebbe essere la base per un tentativo di standardizzazione.
Che ne dite? Qualcuno ha già avuto lo stesso problema?