L'e-mail usa protocolli diversi da quelli del web: SMTP per l'invio, IMAP o POP3 per la lettura. Poiché questi protocolli non sono HTTP, non possono essere trasportati da un proxy HTTP — se non tramite tunnel CONNECT. E anche nel tunnel CONNECT la maggior parte dei provider chiude le porte e-mail.
In questo articolo vediamo cosa è tecnicamente possibile, perché esistono determinate restrizioni e come procedere negli scenari legittimi.
Mappa di protocolli e porte
Poiché la porta 25 è il canale classico degli abusi di spam, viene bloccata ampiamente sia dagli ISP sia dai provider di proxy.
Quale tipo di proxy funziona?
SOCKS5 trasporta nativamente i protocolli e-mail perché non guarda al livello applicativo. La maggior parte dei client e-mail supporta l'impostazione SOCKS5.
Gran parte dei provider di proxy vieta esplicitamente l'invio di e-mail nei propri contratti. Il motivo è il rischio di spam e la tutela della reputazione IP. Prima di usarlo, verifica sempre la policy del tuo provider.
Scenari d'uso legittimi
Esistono ragioni legittime per far passare il traffico e-mail attraverso un proxy:
Accesso all'e-mail da una rete limitata
Se la rete in cui ti trovi blocca le porte IMAP, puoi accedervi con un tunnel SOCKS5 attraverso un tuo server.
Test dell'infrastruttura e-mail
Verificare la raggiungibilità del proprio server di posta da Paesi diversi.
Controllo della deliverability
Verificare se le e-mail che invii finiscono nella posta in arrivo o nello spam in regioni diverse — si tratta di un'operazione di lettura, non di invio.
Accesso tramite canale sicuro
Far passare il client e-mail attraverso un tunnel cifrato su Wi-Fi pubblico.
Esempi di configurazione
Il port forwarding locale via SSH è la soluzione più semplice e sicura per una singola destinazione; non incappi nella policy sulle porte del provider di proxy.
Perché è bloccato? L'economia dello spam
Le blacklist e-mail operano a livello di IP e di blocco. Per questo i provider, vietando l'invio SMTP, proteggono sia se stessi sia gli altri clienti.
Alternativa: le API per e-mail
Se devi inviare e-mail massive, lo strumento giusto non è un proxy ma un servizio e-mail progettato per questo. Questi servizi gestiscono al posto tuo autenticazione, deliverability e reputazione.
| Esigenza | Lo strumento giusto | Il proxy è adatto? |
|---|---|---|
| Invio massivo di e-mail | Provider di servizi e-mail | No |
| E-mail transazionali | Servizio basato su API | No |
| Lettura della posta da una rete limitata | Tunnel SOCKS5 o SSH | Sì |
| Test di raggiungibilità del server | SOCKS5 | Sì |
| Controllo della posta in arrivo da un altro Paese | SOCKS5 | Sì |
Nota su DNS e autenticazione
Quando fai girare il client e-mail attraverso un proxy, assicurati che anche la risoluzione DNS avvenga lato proxy. Altrimenti l'indirizzo del tuo server di posta esce dalla rete locale. In Thunderbird ci pensa la casella "DNS remoto", lato codice lo socks5h schema — i dettagli nel nostro articolo sulla risoluzione DNS con SOCKS5.
Riepilogo
Poiché i protocolli e-mail non sono HTTP, in pratica richiedono SOCKS5; un proxy HTTP è utilizzabile solo tramite tunnel CONNECT e spesso nemmeno quello, a causa delle restrizioni sulle porte. Gran parte dei provider vieta contrattualmente l'invio SMTP — serve a prevenire il rischio reputazionale legato allo spam. In scenari legittimi come la lettura della posta e i test di raggiungibilità, lo strumento giusto è un tunnel SOCKS5 o SSH. Per l'invio massivo, invece, non va usato un proxy ma un provider di servizi e-mail. Per i dettagli di prodotto, visita la nostra pagina sui proxy SOCKS5 puoi consultarlo.