Tema: 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.
-
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.
Legible por máquina: JSON