Why Exchange SMTP Protocol Logs Show Only EHLO and QUIT — Complete RCA and Fix

 

Why SMTP Protocol Logs Don’t Show Full Details in Exchange 2019 (and How to Fix It)

---

🔷 Introduction

While configuring SMTP Relay in Exchange 2019, many administrators notice a common issue:

SMTP protocol logs show only EHLO and QUIT, but not MAIL FROM, RCPT TO, or AUTH.

This can be confusing, especially when mail flow is working correctly.

This article explains:

• Why this happens
• Exchange transport architecture (Frontend vs Backend)
• Real troubleshooting steps
• How to enable full logging
• How to validate SMTP AUTH end-to-end

---

🔷 Problem Statement

Initial protocol logs showed only:

EHLO smtp.availability.contoso.com
QUIT

Even after sending test emails:

• No MAIL FROM
• No RCPT TO
• No AUTH LOGIN

---

🔥 Root Causes Identified

---

✅ 1. Exchange Health Probe Traffic (Not Real Emails)

Exchange continuously performs internal health checks:

EHLO smtp.availability.contoso.com
QUIT

👉 These are:

• System-generated probes
• Not actual email traffic
• Logged frequently across all connectors

---

✅ 2. Frontend Transport Logs Are Limited

Initial logs were from:

FrontEnd\ProtocolLog\SmtpReceive

👉 These logs only capture:

• Connection start
• Minimal SMTP interaction

👉 They do NOT always capture full SMTP conversation for authenticated sessions.

---

✅ 3. Backend (Hub Transport) Logging Was Disabled

Path:

TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive

👉 Folder was empty ❌

Cause:

ProtocolLoggingLevel = None (for Hub connectors)

---

✅ 4. Local Submission (Same Server Optimization)

When using:

Send-MailMessage from Exchange server itself

👉 Exchange optimizes flow:

Internal submission → No full SMTP session

Result:

No MAIL FROM / AUTH logs ❌

---

✅ 5. TLS Certificate Validation Failure

Error observed:

The remote certificate is invalid according to the validation procedure

Cause:

• Certificate not trusted ❌
• CN mismatch OR self-signed ❌

Impact:

TLS handshake fails → AUTH never happens → SMTP stops

---

🔷 Error Scenarios Observed

---

❌ Error 1 — No AUTH

530 5.7.57 SMTP; Client was not authenticated

Cause:

• Authentication not attempted
• TLS not established

---

❌ Error 2 — Certificate Validation Failure

AuthenticationException: remote certificate is invalid

Cause:

• Client does not trust certificate

---

❌ Error 3 — Protocol Logs Showing Only EHLO

EHLO smtp.availability.contoso.com
QUIT

Cause:

• Health probes
• Logging from Frontend only

---

🔷 How We Fixed the Issue

---

✅ Step 1 — Enable Backend Transport Logging

Get-ReceiveConnector | where {$_.TransportRole -eq "HubTransport"} | Set-ReceiveConnector -ProtocolLoggingLevel Verbose

---

✅ Step 2 — Enable Transport Service Logging

Set-TransportService CMHYBD01 -IntraOrgConnectorProtocolLoggingLevel Verbose

---

✅ Step 3 — Restart Transport Service

Restart-Service MSExchangeTransport

---

✅ Step 4 — Use External Server for Testing

Instead of local test:

Run SMTP from another server ✅

---

✅ Step 5 — Fix TLS Validation (Lab Scenario)

Temporary workaround:

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

---

✅ Step 6 — Send Authenticated SMTP Mail

Send-MailMessage -From "smb1@cloudmonkeys.xyz" -To "raghu@cloudmonkeys.xyz" -Subject "Test" -Body "Test" -SmtpServer mail.cloudmonkeys.xyz -Port 587 -UseSsl -Credential $cred

---

🔷 Final Result — Full SMTP Session Captured

Now protocol logs showed:

EHLO clientserver ✅
STARTTLS ✅
AUTH LOGIN ✅
MAIL FROM ✅
RCPT TO ✅
DATA ✅
250 Queued mail ✅

---

🔷 Why Logs Appeared in Hub Protocol Path

Final logs were captured in:

TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive

---

✅ Reason

Exchange transport flow:

Client → Frontend Receive Connector
       → Authentication (TLS)
       → Proxy (XPROXY)
       → Backend Transport (Hub)
       → Mail Processing

---

👉 Therefore:

Stage	Logs
Frontend	Limited (EHLO, TLS)
Backend (Hub)	Full SMTP session ✅

---

🔷 Understanding XPROXY (Advanced)

From logs:

XPROXY SID=... IP=192.168.1.20

👉 Meaning:

• Frontend forwarded connection
• Backend preserved original client identity
• Real SMTP processing happens here

---

🔷 Where We Enabled Verbose Logging

---

✅ Frontend Connector

Set-ReceiveConnector "SMTP Auth Relay Script" -ProtocolLoggingLevel Verbose

---

✅ Hub Transport Connectors

Set-ReceiveConnector (Hub connectors) -ProtocolLoggingLevel Verbose

---

✅ Transport Service

Set-TransportService -IntraOrgConnectorProtocolLoggingLevel Verbose

---

🔷 Validation Checklist

---

✅ Confirm Connector Usage

• Port 587 used ✅
• Authenticated session ✅

---

✅ Confirm Logs

Check:

Frontend logs → initial connection
Hub logs → full SMTP session ✅

---

✅ Confirm Authentication

Look for:

235 Authentication successful ✅

---

✅ Confirm Mail Flow

Message tracking:

Get-MessageTrackingLog

---

---

🔷 Key Learnings

---

✅ 1. Protocol Logs Are Split

Frontend → Partial logs
Backend → Full SMTP logs

---

✅ 2. Health Probes Exist

smtp.availability.contoso.com ≠ Real traffic

---

✅ 3. TLS Is Mandatory for AUTH

No TLS → AUTH fails → MAIL FROM rejected

---

✅ 4. Certificate Must Be Trusted

Else → TLS handshake fails

---

✅ 5. External Testing Is Required

Same-server tests ≠ Full SMTP logs

---

🎯 Final Conclusion

SMTP protocol logs were not showing full details because:
- Logs were checked only at Frontend level
- Backend (Hub) logging was disabled
- Local SMTP submission was optimized
- TLS certificate validation was failing

After enabling backend logging, using external SMTP client, 
and fixing TLS validation, full SMTP sessions including AUTH, 
MAIL FROM, and RCPT TO were successfully captured.