テーマ： 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 の招待：UID、SEQUENCE、タイムゾーンの正しい扱い
iCalendar のイベントは UID で識別し、SEQUENCE で改訂を示す。時刻は UTC、埋め込み VTIMEZONE を参照する TZID 付きのローカル時刻、または浮動時刻で表す。繰り返しの会議にはゾーンに固定したローカル時刻を、単発のゾーン間イベントには UTC を使い、受信クライアントが想定する iTIP METHOD で更新とキャンセルを送る。
-
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.
-
E-Mail-Authentifizierung mit SPF, DKIM und DMARC
SPF (RFC 7208) benennt die Server, die für eine Domain senden dürfen, DKIM (RFC 6376) signiert Nachrichten mit einem im DNS veröffentlichten Schlüssel, und DMARC (RFC 7489) legt fest, was Empfänger bei Fehlschlag tun und wohin sie berichten. Alle drei sind DNS-TXT-Einträge, die jede DNS-Änderung überleben müssen.
-
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構造：multipart/alternative、プレーンテキスト部分、エンコーディング
テキストとHTMLを持つメッセージはmultipart/alternativeで、単純なものから豊かな表現へ並べる（text/plainが先、text/htmlが最後）。非ASCIIバイトを含む本文はquoted-printableまたはbase64を使い、ヘッダーはRFC 2047のencoded-wordを使う。テキスト部分はHTMLと同じデータから生成し、変数をエスケープし、行長の制限を守る。
-
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.
機械可読： JSON