Errore SMTP 501 Syntax error in parameters or arguments

Questa guida analizza errore SMTP 501 Syntax error con controlli progressivi, verifiche incrociate e modifiche reversibili. Non inviare password, token, cookie, chiavi private o credenziali complete nei ticket.

Che cosa significa

Il codice SMTP 501 appartiene agli errori permanenti della famiglia 5xx e segnala che la struttura di un comando oppure uno dei suoi argomenti non rispetta il formato atteso dal server. La sessione può essere già connessa e autenticata correttamente, ma l’invio viene rifiutato quando il server analizza HELO, MAIL FROM, RCPT TO o un parametro ESMTP.

Il testo che segue il codice è essenziale. Messaggi come syntax error in parameters or arguments, bad address syntax o riferimenti a MAIL FROM e RCPT TO indicano punti differenti della conversazione SMTP. Prima di modificare DNS, password o porte bisogna individuare il comando preciso che ha generato la risposta.

Come riconoscere il problema

• Il bounce o il log contiene il codice 501.
• Il testo cita syntax error, bad address syntax o invalid argument.
• L’invio fallisce soltanto da un plugin, un gestionale o un modulo di contatto.
• La Webmail invia correttamente con la stessa casella.
• Uno specifico mittente, destinatario o campo del form fa comparire l’errore.

Non confondere il codice 501 con un problema generico di consegna. Un errore DNS del destinatario, una quota piena o un blocco antispam producono normalmente risposte differenti. Nel 501 il server segnala esplicitamente che non riesce ad accettare la forma del comando ricevuto.

Cause più frequenti

1. Indirizzo email con sintassi non valida

Mittente o destinatario contiene spazi, parentesi non ammesse, caratteri invisibili, una chiocciola mancante oppure un dominio incompleto. Per confermare questa causa confronta il valore originale con quello registrato nella sessione SMTP o nel log. Non correggere più campi contemporaneamente: modifica un solo elemento e ripeti lo stesso invio.

2. Comando MAIL FROM o RCPT TO costruito male

Un’applicazione, un plugin SMTP o uno script genera il comando con delimitatori errati, parentesi angolari mancanti o parametri aggiuntivi non supportati. Per confermare questa causa confronta il valore originale con quello registrato nella sessione SMTP o nel log. Non correggere più campi contemporaneamente: modifica un solo elemento e ripeti lo stesso invio.

3. HELO o EHLO non conforme

Il client si presenta con un hostname vuoto, non valido o formato in modo non conforme e il server rifiuta la sessione prima dell’invio. Per confermare questa causa confronta il valore originale con quello registrato nella sessione SMTP o nel log. Non correggere più campi contemporaneamente: modifica un solo elemento e ripeti lo stesso invio.

4. Header o envelope sender confusi

Il campo From visibile può essere corretto mentre l’envelope sender usato nella busta SMTP contiene una sintassi differente o un valore vuoto. Per confermare questa causa confronta il valore originale con quello registrato nella sessione SMTP o nel log. Non correggere più campi contemporaneamente: modifica un solo elemento e ripeti lo stesso invio.

5. Plugin, modulo di contatto o gestionale

Il software inserisce dati non sanificati provenienti da un form, concatena più indirizzi in modo errato o usa una libreria SMTP obsoleta. Per confermare questa causa confronta il valore originale con quello registrato nella sessione SMTP o nel log. Non correggere più campi contemporaneamente: modifica un solo elemento e ripeti lo stesso invio.

6. Caratteri copiati o codifica anomala

Virgolette tipografiche, spazi non separabili, ritorni a capo e caratteri Unicode invisibili possono rendere non valido un parametro apparentemente corretto. Per confermare questa causa confronta il valore originale con quello registrato nella sessione SMTP o nel log. Non correggere più campi contemporaneamente: modifica un solo elemento e ripeti lo stesso invio.

7. Parametro ESMTP non supportato

Il client invia opzioni come SIZE, BODY, SMTPUTF8 o altri parametri con formato errato oppure non compatibile con il server raggiunto. Per confermare questa causa confronta il valore originale con quello registrato nella sessione SMTP o nel log. Non correggere più campi contemporaneamente: modifica un solo elemento e ripeti lo stesso invio.

Diagnosi passo per passo

1. Conservare la risposta SMTP completa e il comando rifiutato. Esegui il controllo nello stesso ambiente che genera l’errore e registra data, ora e risultato. Quando confronti indirizzi e comandi, visualizza anche caratteri invisibili e delimitatori; una rappresentazione grafica normale può nascondere lo spazio o il ritorno a capo responsabile.
2. Identificare se l’errore avviene su HELO, MAIL FROM o RCPT TO. Esegui il controllo nello stesso ambiente che genera l’errore e registra data, ora e risultato. Quando confronti indirizzi e comandi, visualizza anche caratteri invisibili e delimitatori; una rappresentazione grafica normale può nascondere lo spazio o il ritorno a capo responsabile.
3. Controllare mittente e destinatario carattere per carattere. Esegui il controllo nello stesso ambiente che genera l’errore e registra data, ora e risultato. Quando confronti indirizzi e comandi, visualizza anche caratteri invisibili e delimitatori; una rappresentazione grafica normale può nascondere lo spazio o il ritorno a capo responsabile.
4. Confrontare header From ed envelope sender. Esegui il controllo nello stesso ambiente che genera l’errore e registra data, ora e risultato. Quando confronti indirizzi e comandi, visualizza anche caratteri invisibili e delimitatori; una rappresentazione grafica normale può nascondere lo spazio o il ritorno a capo responsabile.
5. Provare l’invio dalla Webmail con gli stessi indirizzi. Esegui il controllo nello stesso ambiente che genera l’errore e registra data, ora e risultato. Quando confronti indirizzi e comandi, visualizza anche caratteri invisibili e delimitatori; una rappresentazione grafica normale può nascondere lo spazio o il ritorno a capo responsabile.
6. Controllare log Exim o Track Delivery nello stesso minuto. Esegui il controllo nello stesso ambiente che genera l’errore e registra data, ora e risultato. Quando confronti indirizzi e comandi, visualizza anche caratteri invisibili e delimitatori; una rappresentazione grafica normale può nascondere lo spazio o il ritorno a capo responsabile.
7. Disattivare soltanto il plugin o l’integrazione sospetta in staging. Esegui il controllo nello stesso ambiente che genera l’errore e registra data, ora e risultato. Quando confronti indirizzi e comandi, visualizza anche caratteri invisibili e delimitatori; una rappresentazione grafica normale può nascondere lo spazio o il ritorno a capo responsabile.
8. Riprodurre la sessione con un client SMTP conforme. Esegui il controllo nello stesso ambiente che genera l’errore e registra data, ora e risultato. Quando confronti indirizzi e comandi, visualizza anche caratteri invisibili e delimitatori; una rappresentazione grafica normale può nascondere lo spazio o il ritorno a capo responsabile.

Metodo sicuro di diagnosi

Prima di modificare la configurazione, registra il messaggio completo, la data e l’ora con fuso, l’URL o il servizio coinvolto, l’ultima modifica nota e il risultato ottenuto con un secondo strumento. Conserva Ray ID, Message-ID, request ID, transaction ID e codici applicativi quando presenti: questi identificativi collegano la schermata ai log senza richiedere password, cookie, token, chiavi private o codici di autenticazione.

Applica una sola modifica alla volta. Dopo ogni intervento ripeti la stessa operazione con gli stessi dati di test e controlla i log dello stesso intervallo temporale. Cambiare contemporaneamente DNS, cache, PHP, plugin, firewall, database e proxy impedisce di capire quale variazione abbia prodotto il risultato e rende più difficile un rollback affidabile.

Controllo incrociato dei livelli

Un errore visibile nel browser o nel client può essere generato da livelli differenti. Per il web confronta browser, curl, CDN, web server, PHP e applicazione. Per WordPress confronta frontend, wp-admin, Site Health, strumenti sviluppatore, WP-CLI e log. Per MySQL separa client, autenticazione, server, transazione e singola query. Per la posta confronta client, Webmail, coda SMTP, Track Delivery, DNS e risposta del destinatario.

Verifica sempre quale sistema ha prodotto il codice. Header, hostname, percorso del log, stack trace e testo esteso aiutano a distinguere un errore dell’edge da uno dell’origine, un rifiuto del proprio server da uno remoto e un problema PHP da uno del database. Questa distinzione evita interventi sul componente sbagliato.

Backup e reversibilità

Prima di cambiare file, record DNS, database, plugin o regole di sicurezza crea una copia leggibile e annota il valore precedente. Per i database usa backup coerenti e verifica che possano essere ripristinati. Per DNS registra TTL e nameserver autoritativi. Per firewall e proxy conserva l’espressione originale della regola. Una modifica reversibile consente di interrompere il test senza aggiungere un secondo guasto.

Non usare permessi 777, non disattivare globalmente WAF o antispam e non ridurre stabilmente la sicurezza TLS per ottenere una pagina funzionante. Le eccezioni devono essere limitate al percorso, parametro, hostname o sorgente confermati dai log.

Come raccogliere prove utili

Esporta testo e dati originali quando possibile: header HTTP, file .eml, bounce completo, output DNS, righe di log, stack trace e codici di risposta sono più utili di uno screenshot ritagliato. Oscura credenziali e dati personali, ma lascia visibili data, server, status, identificativi e descrizione tecnica dell’errore.

Ripeti il controllo con un caso minimo. Per una API usa pochi campi; per WordPress prova una funzione core; per MySQL usa una query in sola lettura o un campione; per la posta invia un messaggio di testo senza allegati. Aggiungi poi complessità progressivamente fino a individuare il punto nel quale compare il problema.

Interpretare cache, code e ritardi

Non tutti i cambiamenti diventano visibili immediatamente. DNS, cache CDN, cache LiteSpeed, sessioni PHP, connessioni persistenti, code SMTP e cron possono continuare a mostrare lo stato precedente. Verifica il TTL o la durata della cache, usa un nuovo identificativo di richiesta e controlla se il sistema sta elaborando una copia già accodata.

Un retry riuscito non annulla automaticamente l’errore precedente nei log. Confronta sempre l’identificativo della nuova richiesta con quello vecchio e verifica che il risultato sia relativo alla stessa URL, casella, query o operazione.

Verifica prolungata dopo la correzione

Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Considera cache, TTL DNS, code SMTP, cron, lock, connessioni persistenti e processi pianificati.

Conserva temporaneamente backup, valori precedenti ed estratti dei log. Se l’anomalia ricompare, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, picchi di traffico, importazioni e servizi esterni. Documenta causa, correzione e prova finale.

Procedura di risoluzione

1. Correggere la sintassi dell’indirizzo coinvolto. Applica la correzione soltanto al componente confermato, conserva il valore precedente e invia un nuovo messaggio di prova. Controlla il nuovo Message-ID e la nuova sessione nei log per evitare di confondere il risultato con un tentativo precedente.
2. Usare username e dominio completi senza spazi o caratteri invisibili. Applica la correzione soltanto al componente confermato, conserva il valore precedente e invia un nuovo messaggio di prova. Controlla il nuovo Message-ID e la nuova sessione nei log per evitare di confondere il risultato con un tentativo precedente.
3. Correggere MAIL FROM, RCPT TO e parentesi angolari nel codice personalizzato. Applica la correzione soltanto al componente confermato, conserva il valore precedente e invia un nuovo messaggio di prova. Controlla il nuovo Message-ID e la nuova sessione nei log per evitare di confondere il risultato con un tentativo precedente.
4. Impostare un hostname valido per HELO o EHLO. Applica la correzione soltanto al componente confermato, conserva il valore precedente e invia un nuovo messaggio di prova. Controlla il nuovo Message-ID e la nuova sessione nei log per evitare di confondere il risultato con un tentativo precedente.
5. Allineare envelope sender e mittente autorizzato. Applica la correzione soltanto al componente confermato, conserva il valore precedente e invia un nuovo messaggio di prova. Controlla il nuovo Message-ID e la nuova sessione nei log per evitare di confondere il risultato con un tentativo precedente.
6. Aggiornare plugin, libreria SMTP o gestionale. Applica la correzione soltanto al componente confermato, conserva il valore precedente e invia un nuovo messaggio di prova. Controlla il nuovo Message-ID e la nuova sessione nei log per evitare di confondere il risultato con un tentativo precedente.
7. Sanificare e validare i campi provenienti dai form. Applica la correzione soltanto al componente confermato, conserva il valore precedente e invia un nuovo messaggio di prova. Controlla il nuovo Message-ID e la nuova sessione nei log per evitare di confondere il risultato con un tentativo precedente.
8. Rimuovere parametri ESMTP non validi o correggerne il formato. Applica la correzione soltanto al componente confermato, conserva il valore precedente e invia un nuovo messaggio di prova. Controlla il nuovo Message-ID e la nuova sessione nei log per evitare di confondere il risultato con un tentativo precedente.
9. Ritestare con Webmail, applicazione e destinatari differenti. Applica la correzione soltanto al componente confermato, conserva il valore precedente e invia un nuovo messaggio di prova. Controlla il nuovo Message-ID e la nuova sessione nei log per evitare di confondere il risultato con un tentativo precedente.

Controlli finali

• Il client completa HELO o EHLO senza errori.
• MAIL FROM e RCPT TO vengono accettati.
• Webmail e applicazione inviano con gli stessi indirizzi validi.
• Track Delivery non registra nuovi errori 501.
• Mittente, Return-Path e autenticazione restano coerenti.

Prevenzione

• Valida gli indirizzi prima di passarli alla libreria SMTP.
• Usa librerie e plugin aggiornati.
• Impedisci ritorni a capo e caratteri di controllo nei campi del form.
• Documenta envelope sender, From e Reply-To delle applicazioni.
• Monitora i bounce permanenti e raggruppali per codice.

Errori da evitare

• Non cambiare password quando il server segnala un errore di sintassi.
• Non disattivare TLS o autenticazione per aggirare il codice 501.
• Non inserire più destinatari in un singolo campo con separatori non supportati.
• Non condividere credenziali o transcript SMTP contenenti token.
• Non modificare DNS senza un errore che coinvolga realmente la risoluzione.

Quando contattare l’assistenza Xlogic

Apri un ticket quando la sintassi appare corretta ma il server continua a rifiutare il comando, quando l’errore coinvolge più applicazioni oppure quando non hai accesso ai log. Indica:

• data e ora con fuso;
• mittente e destinatario parzialmente oscurati;
• risposta SMTP completa;
• applicazione o plugin utilizzato;
• risultato della prova da Webmail.

Non inviare la password della casella.

Fonti tecniche ufficiali

• SMTP RFC 5321
• cPanel Track Delivery

Domande frequenti su errore SMTP 501 Syntax error