Zaznamenávání konverzací SMTP

Automaticky přeloženo z Deepl

Jak jsme slíbili v předchozím příspěvku, každá verze R obsahuje další pokroky související s funkcemi e-mailu a odemyká jeho skrytou sílu.

4D v17 R5 poskytuje zajímavou novou funkci pro e-mailové protokoly. Někdy se stane, že během vývoje vše funguje v pořádku, ale při nasazení u zákazníka se objeví problém s doručováním e-mailů. Zjistit, kde k selhání došlo, může být obtížné, protože komunikace je šifrovaná a často nemáte přístup k souborům protokolu serveru SMTP. Problém velmi pravděpodobně souvisí s vaším serverem SMTP, ale jak si můžete být jisti? Jednoduše spusťte protokol SMTP ve své aplikaci! Tento protokol obsahuje záznam všech provedených akcí, včetně těch, které zastavují spojení. A co víc, tento protokol zobrazuje komunikaci se serverem SMTP v prostém, nešifrovaném textu, což usnadňuje její analýzu.

Stránka SMTP New transporter příkaz vytvoří spojení se serverem SMTP ( například exchange nebo gmail ) a zaznamená veškerou komunikaci mezi ním a klientem.

Aktivace funkce Záznam transakce SMTP

Chcete-li v databázi aktivovat protokol komunikace SMTP pro všechny odeslané e-maily, můžete použít následující kód:

SET DATABASE PARAMETER(SMTP Log, 1)

Chcete-li na serveru snadno spustit protokol SMTP, klikněte na tlačítko „Spustit protokoly požadavků a ladění“ v okně správy serveru 4D:

Všechny transakce SMTP probíhající na serveru 4D Server budou automaticky zaznamenány.

Záznam konkrétní transakce

Pokud potřebujete zaznamenat konkrétní transakci (například při ladění), můžete použít příkaz logFile objektu SMTP:

$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)

Příklad souboru protokolu SMTP

Každý řádek protokolu obsahuje pět informací:

  • Čítač
  • Datum a čas
  • ID procesu
  • Jedinečné ID procesu
  • příkaz k odeslání od klienta („C >“) nebo odpověď od serveru („S <„) s kódem odpovědi a vráceným popisem.

Zde je výsledek pokusu o připojení s nesprávným heslem:

1 2019-02-06T15:03:11.586 5 7 ### SMTP Připojeno k 'smtp.gmail.com' na portu 465. (zabezpečeno)
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 u vaší služby, [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 Uživatelské jméno a heslo nejsou akceptovány. Více informací na"
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

Podívejme se blíže na to, co se děje v protokolu:

  • Řádek 1: Otevřen komunikační kanál se serverem SMTP přes port 465. Automaticky se spustí šifrování TLS a komunikace je zabezpečena.
  • Řádek 3: Klient odešle příkaz EHLO pro zahájení konverzace SMTP.
  • Řádek 4 až 11: Server vrátí některé konfigurační prvky včetně seznamu podporovaných metod ověřování(řádek 7).
  • Řádek 12: Klient odešle typ ověření.
  • Řádek 14: Klient odešle přihlašovací jméno a heslo. V protokolu se nikdy neobjeví v prostém textu, jsou nahrazeny znaky „*“.
  • Řádek 15 a 16: Server vrátí chybu 535, ověření se nezdařilo.
  • Řádek 17: Klient odešle příkaz „QUIT“, aby uzavřel spojení se serverem.

Jak vidíte na tomto příkladu, je nyní snadné řešit problémy s komunikací.

Šťastné přihlašování!

Fabrice Mainguené
- Product Owner -Fabrice Mainguené se připojil k týmu 4D Program v listopadu 2016. Jako Product Owner má na starosti psaní uživatelských příběhů, které následně převádí do funkčních specifikací. Jeho úkolem je také zajistit, aby dodaná implementace funkcí splňovala potřeby zákazníků.Po získání bakalářského titulu v oboru informatiky na CNAM nastoupil Fabrice do malé softwarové vydavatelské společnosti jako vývojář Windev. Poté pracoval pro různé společnosti v oblasti průmyslu a obchodu jako vývojář aplikací Windev a webových aplikací a také jako technický poradce pro nové funkce.