Topic: email
-
After how many soft bounces, over what period, should a sender stop mailing an address?
Open question: enhanced status codes separate permanent failures (5.X.X) from persistent transient ones (4.X.X), but the standard leaves the transient case to sender policy; which thresholds have senders used, and what happened to recovery rates and reputation?
-
List-Unsubscribe and one-click unsubscribe headers (RFC 2369 and RFC 8058)
RFC 2369 headers let mail clients offer list actions; RFC 8058 one-click adds a List-Unsubscribe HTTPS URI plus List-Unsubscribe-Post: List-Unsubscribe=One-Click, processed by an HTTPS POST with no redirect and no further steps, with both headers covered by DKIM. Bulk senders are required by Google's guidelines to support it.
-
iCalendar invites: UID, SEQUENCE and getting time zones right
An iCalendar event is identified by UID and revised by SEQUENCE; its times are UTC, local time with a TZID that refers to an embedded VTIMEZONE, or floating. Use zone-anchored local time for recurring meetings, UTC for one-off cross-zone events, and send updates and cancellations with the iTIP METHOD the receiving client expects.
-
Email authentication: SPF, DKIM and DMARC
SPF lists the servers allowed to send for a domain, DKIM signs messages with a domain key, DMARC tells receivers what to do when both fail and where to send reports; all three are DNS TXT records that must stay in place when other records change.
-
Email authentication with SPF, DKIM and DMARC
SPF (RFC 7208) names the servers allowed to send for a domain, DKIM (RFC 6376) signs messages with a key published in DNS, and DMARC (RFC 7489) defines what receivers do on failure and where they send reports. All three are DNS TXT records that must survive every DNS change.
-
Sending transactional email reliably: outbox row, worker, retries and idempotency keys
Do not send mail from the request handler: record the message in the same transaction as the business event, let a worker deliver it, retry transient (4yz) replies and connection failures with backoff, stop on permanent (5yz) replies, and prevent duplicates after a crash with a per-event idempotency key and a stable Message-ID.
-
One-click unsubscribe headers lower spam-complaint rates compared with a footer link alone
Hypothesis: for the same list and content, messages carrying RFC 8058 List-Unsubscribe and List-Unsubscribe-Post headers receive fewer 'report spam' actions per delivered message than messages with only a footer link, because the mail client offers unsubscription next to the spam button; a randomised split test is proposed.
-
Validating email addresses: what a syntax check can and cannot tell you
RFC 5321 caps the local-part at 64 octets and a path at 256; the HTML standard deliberately uses a simpler grammar than RFC 5322 for input type=email; internationalised addresses need SMTPUTF8 end to end. Check syntax and lengths, look up MX at signup, confirm ownership with a message, and never 'correct' an address automatically.
-
MIME structure of an email: multipart/alternative, the plain-text part and encodings
A text-plus-HTML message is a multipart/alternative whose parts are ordered from plainest to richest (text/plain first, text/html last); bodies with non-ASCII bytes use quoted-printable or base64, headers use RFC 2047 encoded-words. Generate the text part from the same data as the HTML, escape variables, and respect line-length limits.
-
Handling bounces and complaints: DSNs, enhanced status codes and feedback loops
Bounces arrive as delivery status notifications whose Status field is an enhanced code of the form class.subject.detail: 5.X.X is permanent, 4.X.X persistent transient; complaints arrive as ARF feedback reports. Parse both, suppress addresses on evidence, and keep the raw diagnostics.
Machine-readable: JSON