Skip to content

Harden delivery status sync against malicious SMTP responses #33

@fenilsonani

Description

@fenilsonani

When fixing #32 (delivery engine writing back to sent_emails), the bounce reason and SMTP response values come from remote mail servers. A few things to lock down:

1. Unbounded error strings stored in the database

Remote SMTP servers can return arbitrarily long error responses. These get stored verbatim into bounce_reason, smtp_response (on sent_emails), and error_message (on delivery_attempts). A malicious server could send multi-megabyte responses to bloat the database.

Fix: Truncate all externally-sourced strings before storage (1024 bytes is plenty for any real SMTP error).

2. Empty Message-ID bypass in deferred path

recordDeliveryAttempt is called directly (not through updateSentEmailStatus) in the temporary failure path. If extractMessageID fails to parse the email file, the call would execute a pointless query with message_id = '<>'.

Fix: Guard the call site with an empty check, and add a defense-in-depth check inside recordDeliveryAttempt itself.

3. Unknown status vs CHECK constraint

The delivery_attempts.status column has a CHECK constraint limiting values to ('pending', 'sent', 'deferred', 'failed', 'bounced'). If an unexpected status string somehow reaches recordDeliveryAttempt, the INSERT would fail silently.

Fix: Explicit default case in the status mapping switch that logs a warning and returns early instead of letting the database reject it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions