Skip to main content

6. Problem Detection and Handling

This section addresses how SMTP implementations should handle various problems that arise during mail transmission.

6.1. Reliable Delivery and Replies by Email​

Delivery Status Notifications (DSN)​

When mail cannot be delivered, the sending system should generate a Delivery Status Notification (bounce message) to inform the sender.

DSN Requirements:

  • MUST be sent to the reverse-path (MAIL FROM address)
  • MUST use null reverse-path (MAIL FROM:<>) to prevent loops
  • SHOULD include original message or headers
  • SHOULD specify reason for failure

Example Bounce Message:

From: [email protected]
To: [email protected]
Subject: Undelivered Mail Returned to Sender

Your message to [email protected] could not be delivered:

  550 5.1.1 Mailbox does not exist

--- Original message headers follow ---
From: [email protected]
To: [email protected]
Subject: Important message
...

Success Notifications​

Delivery success notifications are generally NOT sent, as they create additional traffic. However, DSN extension allows explicit requests for positive delivery confirmation.

Timeouts and Retries​

Retry Schedule:

  • Initial failure: Retry after 30 minutes
  • Subsequent failures: Exponential backoff (1 hour, 2 hours, 4 hours, etc.)
  • Maximum retry period: At least 4-5 days
  • Final failure: Send bounce to sender

Warning Messages:

  • After 4-6 hours: Send delay warning to sender
  • Include reason for delay
  • Inform sender that delivery attempts continue

6.2. Unwanted, Unsolicited, and "Attack" Messages​

SMTP servers should implement protections against abuse:

Spam Prevention​

Techniques:

  1. Recipient Verification: Verify recipient exists before accepting mail
  2. Sender Verification: Check SPF, DKIM, DMARC
  3. Rate Limiting: Limit messages per connection/hour
  4. Greylisting: Temporarily reject first-time senders
  5. Content Filtering: Scan message content for spam patterns
  6. Reputation Systems: Track sender reputation

Denial of Service (DoS) Protection​

Defenses:

  1. Connection Limits: Limit concurrent connections from single IP
  2. Rate Limiting: Limit commands per second
  3. Tarpit: Slow down suspicious senders
  4. Resource Limits: Cap CPU and memory usage per connection
  5. Timeout Enforcement: Disconnect idle connections

Directory Harvest Attacks (DHA)​

Attackers send RCPT TO commands with guessed addresses to find valid mailboxes.

Countermeasures:

❌ Vulnerable:
C: RCPT TO:``<[email protected]>``
S: 550 No such user        (reveals invalid)
C: RCPT TO:``<[email protected]>``
S: 250 Ok                  (reveals valid)

✅ Protected:
- Delay responses to RCPT commands
- Use same response for valid and invalid (e.g., always "250 Ok")
- Verify recipient only during or after DATA
- Rate limit RCPT commands

Backscatter Prevention​

Backscatter: Bounces sent to forged sender addresses, creating collateral spam.

Prevention:

  1. Reject at SMTP Time: Reject invalid recipients during SMTP transaction (before DATA)
  2. Verify Sender: Don't accept mail from forged senders
  3. Don't Generate Bounces: For mail from unknown/suspicious sources
✅ Good Practice:
C: RCPT TO:``<[email protected]>``
S: 550 5.1.1 User unknown    (reject immediately)

❌ Bad Practice:
C: RCPT TO:``<[email protected]>``
S: 250 Ok                    (accept mail)
(later generate bounce to forged sender)

6.3. Loop Detection​

Mail loops occur when messages are repeatedly forwarded through the same servers.

Detection Methods​

Method 1: Received Header Count

Count Received headers in message
If count > 100:
  Reject with "554 5.4.6 Too many hops"

Method 2: Received Header Analysis

Parse Received headers
Check if current server appears multiple times
If yes:
  Detect loop and reject

Method 3: Message-ID Tracking

Remember Message-ID of recently processed messages
If same Message-ID seen again within short time:
  Likely a loop, reject

Loop Prevention​

Best Practices:

  1. Limit Hops: Reject after 50-100 Received headers
  2. Detect Patterns: Identify repeating server names in trace
  3. Break Loops: Don't forward mail that appears to be looping
  4. Configuration Review: Avoid forwarding rules that create loops

Example Loop:

mail.a.example → mail.b.example →
mail.c.example → mail.a.example (loop!)

6.4. Compensating for Irregularities​

Real-world SMTP implementations sometimes deviate from standards. Robust implementations should handle common irregularities gracefully.

Common Irregularities​

1. Extra Whitespace​

Some implementations send extra spaces:

❌ Non-standard:
C: MAIL  FROM: ``<[email protected]>``    (extra spaces)

✅ Robust handling:
Accept and parse correctly

2. Mixed Case Commands​

❌ Non-standard:
C: Mail From:``<[email protected]>``

✅ Robust handling:
Treat as case-insensitive

3. Missing Angle Brackets​

Some old systems omit <> around addresses:

❌ Non-standard:
C: MAIL FROM:[email protected]

✅ Robust handling:
Accept both with and without brackets

4. CR or LF Only (Not CRLF)​

Standard requires CRLF (\r\n), but some send only LF (\n) or CR (\r):

✅ Robust handling:
Accept CR, LF, or CRLF as line terminator
(but always send CRLF)

5. Long Lines​

Some implementations send lines exceeding limits:

✅ Robust handling:
- Accept lines longer than 512 octets
- Split internally if needed
- Don't break during SMTP transaction

Robustness Principle​

"Be conservative in what you send, liberal in what you accept"

  • Send: Strictly conform to standards
  • Receive: Accept minor deviations gracefully
  • Log: Record non-standard behavior
  • Don't: Silently fix and forward (maintains interoperability problems)

Error Recovery​

When encountering irregularities:

Option 1: Accept and Proceed

Log warning
Process message normally

Option 2: Accept with Notification

Log warning
Process message
Send DSN to postmaster about issue

Option 3: Reject

Only for severe violations
Provide clear error message
Log for analysis

Testing for Compliance​

Implementers should test against:

  • Standards-compliant servers: Verify correct operation
  • Known broken implementations: Ensure interoperability
  • Malformed input: Test error handling
  • Edge cases: Boundary conditions and unusual scenarios
Last updated on