That's not how email works

Email tracking pixels and deliverability

• Several comments explain that Gmail (and some other providers) prefetch remote images via a proxy, caching them server-side. This breaks open-rate tracking but still reveals that a mailbox exists if the provider only fetches for delivered mail.
• Others note: providers already send explicit bounce notifications for non-existent addresses, so pixels are a poor way to test validity.
• Some argue pixels still “work” for existence checks; others say the correct method is simply to send an email and look for bounces.
• Apple Mail’s “Protect Mail Activity” is reported not to work reliably in all cases; tracking signals remain noisy overall.
• Email-marketing tools are criticized for presenting “opens” as hard data. People inside large orgs and startups reportedly over-trust these metrics because they look good, even though they’re largely unreliable.

Banks using pixels to drive paper mail

• Multiple banks (HSBC, Capital One, NAB, Schwab, Fidelity, Ameriprise, Apple Card issuer, etc.) are reported to send physical letters or revert to paper when tracking indicates emails aren’t being “read,” even though customers are receiving them.
• Some banks even disable alerts or paperless settings based on lack of open-tracking, which users find both illogical and costly.

Do banks care if you leave?

• One view: cancelling accounts has limited impact; retail accounts aren’t very profitable, and banks can borrow reserves elsewhere.
• Counterview: net interest margin and fees still matter; deposits (including retail) underpin lending and provide political clout, so retention is important in aggregate even if one account is negligible.
• Some suggest regulatory complaints are more effective leverage than switching, at least in jurisdictions with responsive regulators.

Why such a bad feature exists

• Several commenters think the tracking-based “are you reading our mail?” system likely went through long internal bureaucracy where:
  • Business wanted proof customers got emails.
  • Tech warned that perfect detection is impossible and pixels are imperfect.
  • Management chose the cheapest, easiest metric anyway and later repurposed it for compliance-ish workflows.
• Others describe culture in big banks and enterprises where ICs are ignored, learned helplessness is common, and legacy systems are treated like untouchable plumbing.

HTTP vs HTTPS and security

• The article’s criticism of HTTP tracking pixels sparks debate:
  • Some argue HTTP leaks per-email identifiers to anyone on the same network, making tracking more intrusive.
  • Others say DNS/SNI already expose the bank domain; they see the marginal risk as small and the focus on protocol as overstated.
• A few point out that any unencrypted content fetch is an attack vector (MITM, image-parsing exploits), but others note that targeting a tracking pixel via MITM is a comparatively awkward attack path.

Alternatives and better practices

• Suggested better patterns:
  • Rely on standard bounce handling for delivery status.
  • Make statements available in online banking and consider them “delivered” when fetched.
  • Notify users within the authenticated session (banner after login) about email problems instead of links or tracking.
  • For explicit confirmation, possibly “reply to this email” rather than click-tracking.
• Some propose that HTML email and remote images are the core issue; using plain text or “simple HTML” modes would block most of this tracking.

Speculation vs evidence

• A subset of commenters stress the post is speculative: there’s no direct proof HSBC’s paper-letter workflow is triggered specifically by pixel non-load rather than a buggy bounce detector or other signal.
• Others think the circumstantial evidence (tracking URL, wording, behavior) makes the guess plausible but agree it’s not proven.