Starting emails with "BEGIN PGP MESSAGE" will fool the filter
A university email filter that rewrites URLs to pass them through a security scanner is being bypassed simply by starting messages with “BEGIN PGP MESSAGE,” exploiting an exemption meant for signed PGP mail. Commenters use this to highlight how brittle many corporate filtering and security mechanisms are—whether URL rewriters, attachment-type filters, or antivirus heuristics—and how attackers routinely adapt faster than these systems evolve. The thread also touches on related usability and security trade-offs, from JavaScript-heavy Mastodon pages to encrypted attachments and “magic link” logins that break when automated scanners follow links.
PGP-Header Trick and Mail Filters
- A university mail filter exempts PGP‑signed emails from URL rewriting, so users prepend “BEGIN PGP MESSAGE” to bypass the rewrite, without actually using PGP.
- Commenters note this likely also helps attackers, undermining the filter’s purpose.
- Some see value in non‑standard configs that reduce noise in detection systems, but stress that “passed the filter” never means “safe.”
Mastodon Content and JavaScript
- The Mastodon post’s text is present in HTML
<meta>but hidden unless JavaScript runs; users share CSS and/embedtricks or using one’s own instance to view content without remote JS. - Some criticize Mastodon for hiding content while it’s already in HTML, arguing this mimics profit‑driven corporate patterns and breaks non‑JS usability.
- Others counter that, compared to current Twitter, Mastodon is more usable for logged‑out users, though both are JS‑dependent.
Email Rewriting, Encryption, and DKIM
- Several commenters strongly dislike in‑transit rewriting of email bodies (including Proton‑style modifications).
- Discussion of DKIM notes an optional length field and lax whitespace handling, which can allow limited body changes without breaking signatures, but also opens room for visual overlay tricks.
- Validating PGP signatures server‑side is seen as difficult due to end‑to‑end models, lack of global key directories, and encrypted payloads; commercial tools exist but are limited.
Attachment and File-Type Filtering
- Corporate filters often block by file extension; some inspect contents, but encrypted archives (especially with visible filenames) remain a gap.
- Techniques to encrypt zip filenames or use 7z are mentioned, balanced against deployability to non‑technical recipients.
- There’s debate on whether content‑based type detection is practical; one view is that it’s error‑prone and best suited to “known bad” reduction, another points to tools like Magika being deployed.
Security as “Speedbumps,” Not Perfection
- Multiple comments emphasize probabilistic thinking: raising the cost of attacks is valuable even if bypasses exist.
- Others warn that overly aggressive filters push users to unsafe workarounds (e.g., renaming extensions, using personal mail), eroding overall security.
Historical and Related Quirks
- Nostalgic examples: “begin 644” or similar strings confusing Outlook/Outlook Express and hiding message bodies; mbox lines starting with “From ” corrupting mail if not escaped.
- URL‑checking filters that actively visit links can break magic login links, despite HTTP semantics that GET should be non‑state‑changing.