Porta SMTP 25 bloccata: "Connection timed out" su AWS, Azure, GCP, VPS

Cosa significa

Per consegnare un'email, il tuo server si connette al server di posta del destinatario sulla porta 25. Se quella connessione non riceve mai risposta, probabilmente la tua rete o il tuo hosting blocca la porta 25 in uscita. I messaggi restano in coda e alla fine vengono restituiti dopo diversi giorni.

L'errore di solito è simile a questo, a seconda del software:

connect to gmail-smtp-in.l.google.com[142.250.27.26]:25: Connection timed out
Error: connect ETIMEDOUT 203.0.113.50:25
SMTP ERROR: Failed to connect to server: Connection timed out (110)

"Timed out" (nessuna risposta) indica un blocco. "Connection refused" o una risposta 5xx sono un problema diverso, dall'altra parte.

Perché succede

Gli spammer amano noleggiare server economici, quindi la maggior parte dei provider blocca la porta 25 in uscita per impostazione predefinita. Le policy cambiano, quindi consulta la documentazione aggiornata del tuo provider. Al momento in cui scriviamo:

• Amazon EC2 e Lightsail limitano la porta 25 in uscita per impostazione predefinita. Puoi chiedere ad AWS di rimuovere il limite con il loro modulo di richiesta, spiegando il tuo utilizzo. L'alternativa è Amazon SES sulla porta 587 o 465.
• Google Cloud (Compute Engine) blocca le connessioni in uscita verso la porta 25 di indirizzi esterni. Google consiglia un servizio di posta su un'altra porta.
• Microsoft Azure blocca la porta 25 in uscita per la maggior parte dei tipi di abbonamento; solo alcuni contratti enterprise possono inviare direttamente. Microsoft consiglia un relay autenticato.
• DigitalOcean blocca SMTP sui Droplet per impostazione predefinita; secondo le segnalazioni della community, il blocco può includere le porte 465 e 587.
• Le connessioni internet di casa e dell'ufficio di solito bloccano anche la porta 25. Gli IP residenziali sono inoltre nelle blocklist, quindi inviare direttamente da casa raramente funziona comunque.

Come verificare

Dal server stesso, testa la porta 25 verso un grande server di posta, poi una porta di invio (submission):

nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.gmail.com 587

Se la 587 si connette e la 25 va in timeout, il blocco è sulla tua rete o presso il tuo provider, non da Google. Controlla anche il tuo firewall (ufw status, iptables -L OUTPUT) e le regole del firewall cloud o del security group per il traffico in uscita.

Su Postfix, postqueue -p elenca i messaggi bloccati con il motivo. Quando hai un percorso funzionante, invia un test all'indirizzo unico indicato nella home page di Delivmail per controllare l'intero percorso.

Come risolvere

Opzione 1: chiedere al provider di sbloccare la porta 25

Alcuni provider (per esempio AWS) accettano una richiesta. Di solito devi spiegare cosa invii, impostare un nome di DNS inverso e mantenere bassi i reclami. Prima di farlo, leggi la checklist per il proprio server di posta: un nuovo IP cloud non ha alcuna reputazione.

Opzione 2: usare un relay tramite un servizio di posta sulla porta 587

È la soluzione abituale. Il tuo server invia a un servizio email (il tuo provider di posta o un servizio transazionale) sulla porta 587 con un login, e quel servizio consegna sulla porta 25 dai propri IP con buona reputazione. Molti servizi accettano anche la porta 2525 o un'API HTTP se anche la 587 è bloccata. Esempio Postfix, in main.cf:

relayhost = [smtp.your-provider.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

E in /etc/postfix/sasl_passwd:

[smtp.your-provider.com]:587   username:password

chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
systemctl reload postfix

In un'applicazione (nodemailer, PHPMailer…), usa l'host del servizio con port: 587 e STARTTLS invece di una connessione diretta.

Poi autentica il relay

Il relay invia da nuovi IP, quindi aggiungilo all'SPF e attiva la sua firma DKIM per il tuo dominio; vedi autenticare il tuo dominio negli strumenti di invio. Altrimenti otterrai un SPF fail: server non autorizzato.

Verifica che sia risolto

Svuota la coda (postqueue -f) e osserva il log: dovresti vedere status=sent con il tuo host di relay. Invia un nuovo test Delivmail e verifica che SPF, DKIM e DMARC passino per il relay, poi reinvia all'indirizzo per cui l'invio era fallito.