Log your SMTP conversations

As promised in a previous post, each R-release includes more advances related to email functionality, unlocking its hidden power.

4D v17 R5 provides an interesting new feature for email logs. Sometimes during development everything works fine but when you deploy to the customer, there’s a problem delivering emails. Discovering where the failure occurs can be difficult, since the communication is encrypted and you often don’t have access to the SMTP server log files. The problem is very likely related to your SMTP server, but how can you be sure? Simply start the SMTP log in your application! This log contains a record of all the actions performed, including those stopping the connection. Even better, this log shows the communications with the SMTP server in plain, non-encrypted text, making it easier to analyze.

The SMTP New transporter command creates a connection with an SMTP server (such as exchange or gmail) and logs all communications between it and the client.

Activate Log SMTP transaction

To enable the SMTP communication log in your database for all emails sent, you can use the following code:

SET DATABASE PARAMETER(SMTP Log, 1)

To easily run an SMTP log on the server, click the “Start Request and Debug Logs” button in the 4D Server Administration window: 

All SMTP transactions running on 4D Server will be automatically logged.

Log a specific transaction

If you need to log a specific transaction (during debugging, for example), you can use the logFile property of the SMTP object:

$server.host:="yoursmtpserver.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)

SMTP Log file example

Each line of the log contains five pieces of information:

• Counter
• Date and time
• Process ID
• Unique process ID
• Sending statement from the client (“C >”) or the response from the server (“S <“) with the reply code and the description returned. 

Here’s the result from trying to connect with an incorrect password:

1 2019-02-06T15:03:11.586 5 7 ### SMTP Connected to 'smtp.gmail.com' on port 465. (secured)
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 at your service, [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 Username and Password not accepted. Learn more at"
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

Let’s take a closer look at what’s happening in the log:

• Line 1: Open a communication channel to SMTP server over port 465. TLS encryption is started automatically and the communication is secured.
• Line 3: Client sends EHLO command to initiate the SMTP conversation.
• Line 4 to 11: Server returns some configuration elements including the list of supported authentication methods (line 7).
• Line 12: Client sends the authentication type.
• Line 14: Client sends the login and password. They never appear in plain text in the log, they’re replaced by “*”s.
• Line 15 and 16: Server returns error 535, authentication failed.
• Line 17: Client sends “QUIT” command to close the connection with the server.

As you can see with this example, it’s now easy to troubleshoot communication issues.

Happy logging!