Come promesso in un post precedente, ogni release R include ulteriori progressi relativi alla funzionalità di posta elettronica, sbloccandone le potenzialità nascoste.
4D v17 R5 offre una nuova interessante funzionalità per i log delle e-mail. A volte durante lo sviluppo tutto funziona bene, ma quando si distribuisce al cliente si verifica un problema nella consegna delle e-mail. Scoprire dove si verifica il guasto può essere difficile, poiché la comunicazione è criptata e spesso non si ha accesso ai file di log del server SMTP. È molto probabile che il problema sia legato al server SMTP, ma come si può essere sicuri? Basta avviare il log SMTP nella vostra applicazione! Questo registro contiene una registrazione di tutte le azioni eseguite, comprese quelle che interrompono la connessione. Ancora meglio, questo registro mostra le comunicazioni con il server SMTP in testo semplice e non criptato, rendendone più facile l’analisi.
Il comando SMTP New transporter crea una connessione con un server SMTP (come Exchange o Gmail) e registra tutte le comunicazioni tra questo e il client.
Attivare il log delle transazioni SMTP
Per attivare il log delle comunicazioni SMTP nel database per tutte le e-mail inviate, è possibile utilizzare il seguente codice:
SET DATABASE PARAMETER(SMTP Log, 1)
Per eseguire facilmente un registro SMTP sul server, fare clic sul pulsante “Avvia registri di richiesta e di debug” nella finestra di amministrazione del server 4D:
Tutte le transazioni SMTP in esecuzione sul Server 4D verranno registrate automaticamente.
Registrare una transazione specifica
Se è necessario registrare una transazione specifica (ad esempio, durante il debug), è possibile utilizzare la proprietà logFile dell’oggetto SMTP:
$server.host:="yourmtpserver.com"
$server .user:="login"
$server .password:="psw"
// Enter the path of the log file you want to create
$server .logFile:="C:\tmp\SMTPLog.txt"
$transporter :=SMTP New transporter($server)
Esempio di file di registro SMTP
Ogni riga del log contiene cinque informazioni:
- Contatore
- Data e ora
- ID processo
- ID univoco del processo
- Dichiarazione di invio dal client (“C >”) o risposta dal server (“S <“) con il codice di risposta e la descrizione restituita.
Ecco il risultato del tentativo di connessione con una password errata:
1 2019-02-06T15:03:11.586 5 7 ### SMTP Connesso a 'smtp.gmail.com' sulla porta 465. (protetto)
2 2019-02-06T15:03:12.142 5 7 S < "220 smtp.gmail.com ESMTP y139sm19463388wmd.22 - gsmtp"
3 2019-02-06T15:03:12.143 5 7 C > "EHLO [192.168.18.9]"
4 2019-02-06T15:03:12.154 5 7 S < "250-smtp.gmail.com al vostro servizio, [195.68.52.79]"
5 2019-02-06T15:03:12.154 5 7 S < "250-SIZE 35882577"
6 2019-02-06T15:03:12.154 5 7 S < "250-8BITMIME"
7 2019-02-06T15:03:12.154 5 7 S < "250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH"
8 2019-02-06T15:03:12.154 5 7 S < "250-ENHANCEDSTATUSCODES"
9 2019-02-06T15:03:12.161 5 7 S < "250-PIPELINING"
10 2019-02-06T15:03:12.161 5 7 S < "250-CHUNKING"
11 2019-02-06T15:03:12.161 5 7 S < "250 SMTPUTF8"
12 2019-02-06T15:03:12.162 5 7 C > "AUTH PLAIN"
13 2019-02-06T15:03:12.168 5 7 S < "334 "
14 2019-02-06T15:03:12.168 5 7 C > "********************************"
15 2019-02-06T15:03:12.234 5 7 S < "535-5.7.8 Nome utente e password non accettati. Ulteriori informazioni su"
16 2019-02-06T15:03:12.234 5 7 S < "535 5.7.8 https://support.google.com/mail/?p=BadCredentials y139sm19463388wmd.22 - gsmtp"
17 2019-02-06T15:03:12.235 5 7 C > "QUIT"
18 2019-02-06T15:03:12.242 5 7 S < "221 2.0.0 closing connection y139sm19463388wmd.22 - gsmtp"
19 2019-02-06T15:03:12.242 5 7 #### SMTP Connection closed67 2019-01-10T11:00:08.653 -5 #### SMTP Connection closed
Diamo un’occhiata più da vicino a ciò che accade nel log:
- Riga 1: Aperto un canale di comunicazione con il server SMTP sulla porta 465. La crittografia TLS viene avviata automaticamente e la comunicazione è protetta.
- Riga 3: Il client invia il comando EHLO per avviare la conversazione SMTP.
- Dariga 4 a 11: il server restituisce alcuni elementi di configurazione, tra cui l’elenco dei metodi di autenticazione supportati(riga 7).
- Riga 12: il client invia il tipo di autenticazione.
- Riga 14: il client invia il login e la password. Non appaiono mai in chiaro nel log, ma sono sostituiti da “*”.
- Righe 15 e 16: il server restituisce l’errore 535, autenticazione fallita.
- Riga 17: Il client invia il comando “QUIT” per chiudere la connessione con il server.
Come si può vedere da questo esempio, ora è facile risolvere i problemi di comunicazione.
Buon logging!