<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Transactions on brtkwr.com</title><link>https://brtkwr.com/tags/transactions/</link><description>Recent content in Transactions on brtkwr.com</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 17 Jul 2026 12:00:00 +0000</lastBuildDate><atom:link href="https://brtkwr.com/tags/transactions/index.xml" rel="self" type="application/rss+xml"/><item><title>Don't put a long token in an email URL</title><link>https://brtkwr.com/posts/2026-07-17-the-404-that-mail-providers-caused/</link><pubDate>Fri, 17 Jul 2026 12:00:00 +0000</pubDate><guid>https://brtkwr.com/posts/2026-07-17-the-404-that-mail-providers-caused/</guid><description>&lt;h2 id="tldr">
 TL;DR
 &lt;a class="heading-link" href="#tldr">
 &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading">&lt;/i>
 &lt;span class="sr-only">Link to heading&lt;/span>
 &lt;/a>
&lt;/h2>
&lt;p>Put a long signed token in an email link and you have built a bug that fires deterministically for some recipients and never for others. MIME quoted-printable wraps lines at column 76, some mail providers re-encode the message and mangle the escape that lands on the wrap seam, and if the first seam falls inside the token a single flipped character makes the signature stop matching. The page returns 404. The fix is to keep the URL credential short, an opaque id resolved server-side. But that swap turns a stateless credential into a stateful one, and there is a whole family of transaction-ordering traps waiting on the other side. Those traps are the more interesting part.&lt;/p></description></item></channel></rss>