Email lowercased and trimmed before storage
Why it matters
Email addresses are case-insensitive per RFC 5321, but most databases store them as case-sensitive strings. Without normalization, Alice@Example.com and alice@example.com are stored as separate contacts, breaking deduplication, suppression lookups, and unsubscribe processing. The CAN-SPAM Act (§ 5) requires that unsubscribe requests be honored within 10 business days — if the suppression lookup misses an address due to case mismatch, the sender is in violation. GDPR Art. 17 right-to-erasure requests face the same risk: a deletion keyed on the normalized form misses records stored in a different case. CWE-20 applies to the failure to normalize input before persistence.
Severity rationale
Critical because case mismatch silently breaks suppression lookups and unsubscribe processing, creating direct CAN-SPAM compliance exposure and duplicate sends to the same person.
Remediation
Normalize email to lowercase and trim whitespace at the point of storage — not at display time. Enforce it at the database level as well:
const normalizedEmail = rawEmail.trim().toLowerCase()
await db.contact.upsert({
where: { email: normalizedEmail },
update: { updated_at: new Date() },
create: { email: normalizedEmail }
})
Add a PostgreSQL check constraint to prevent non-lowercase values reaching the column:
ALTER TABLE contacts ADD CONSTRAINT email_lowercase
CHECK (email = lower(email));
Run a backfill migration before adding the constraint: UPDATE contacts SET email = lower(trim(email));. Apply the same normalization to suppression lookups — a suppression table keyed on mixed-case emails defeats the dedup entirely.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Data Quality & List Hygiene Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-20 — Improper Input Validation
- iso-25010:2011 · functional-correctness — Functional Correctness (functional suitability)
- gdpr · Art. 17 — Right to erasure ('right to be forgotten')
Taxons
History
- 2026-04-18·v1.0.0·Initial import from data-quality-list-hygiene·automated