51 releases 59 tags

RSS feed

• v0.22.0 6ce25a44fe

  Compare

  v0.22.0 Stable

  joeyr released this 2026-08-19 23:11:51 -05:00 | 41 commits to main since this release

  The mail tenant can see the junk folder, and can tell you why a message is a phish.
  Prompted by a brand-impersonating message in the live INBOX that nothing on the read
  surface could characterise. Two probes settled the design before any of it was written,
  and both overturned the assumption the work started from.

  iCloud sends no \Junk attribute, so discovery finds nothing and the folder name has
  to be configured — the opposite ordering from what special-use suggests. And iCloud does
  not stamp one combined Authentication-Results header: it writes four to six of them,
  one verdict each, every one with its own authserv-id. The usual "trust only the topmost
  instance" rule reads bimi=skipped there and would have reported that every message in
  the mailbox carries no authentication data at all.

  The finding that reordered the work: the message that prompted it passes SPF, DKIM and
  DMARC with every domain aligned. The sender owned the domain they sent from and signed
  their own mail correctly, while impersonating an unrelated brand in the display name, the
  body and the links. Authentication results would have given it a clean bill of health, so
  the header-hygiene signals — not the authentication block — are what catch it.

  Added

  • get_message_security, a read tool registered with no write grant required, on the
    argument that seeing a message is a phish must not require the ability to move it. It
    returns hygiene signals, parsed authentication results and an assessment sentence
    together in one response, deliberately not as two tools: a caller handed the
    authentication block alone sees four green verdicts and reports a phish as genuine.

  • icloudmail/hygiene.py — six sender-independent signals, all network-free and
    fixture-tested: invisible and bidi characters in the display name, subject or Reply-To;
    Latin/Cyrillic-or-Greek homoglyphs within a single word; a brand in the display name
    absent from the sending domain; a Re:/Fwd: prefix with no In-Reply-To or
    References; a Reply-To on another domain; and the recipient's own address, plain, hex
    or base64, inside the unsubscribe link. Every flag carries its evidence and the field it
    came from — no score, no is_phishing boolean.

  • icloudmail/authresults.py — SPF, DKIM, DMARC and ARC as the receiving MTA recorded
    them. Nothing is recomputed: SPF cannot be re-evaluated after delivery, and re-verifying
    DKIM would manufacture failures a middlebox already caused. Trust is keyed per method
    to the authserv-id that reported it, so a forged header cannot outvote the real one by
    sitting above it, and anything outside the boundary is labelled untrusted_claims rather
    than merged.

  • JUNK_FOLDER (default Junk) and MAIL_AUTHSERV_DOMAIN (default icloud.com),
    with a preflight advisory when the junk folder is not in MAIL_FOLDERS — a mismatch that
    otherwise fails silently, leaving the folder readable but untagged.

  • probes/m5_verify.py, the repeatable read-only live check. 16 checks against the real
    mailbox, all passing, driven through the tool layer rather than the client.

  Changed

  • list_folders tags the configured junk folder role: "junk" when the server
    volunteers no attribute, config first and \Junk second — the same resolution order as
    trash_folder, for the same reason. A real attribute still wins.

  • get_message carries hygiene_flags and a hygiene_note, names only and only when
    something fired, so an ordinary read pays nothing for it. Without the pointer a reader
    never learns the second tool exists, and the signals would be absent from exactly the
    messages they were written for.

  • DKIM verdicts always travel with their signing domain and an aligned boolean. A
    valid signature proves only that the signing domain sent the message, and a phisher
    signs their own mail and passes.

  • DMARC deliberately carries no aligned key. Its header.from is the From domain,
    so comparing them returns true on a forged message too — a security check that cannot
    fail is worse than no field. It reports evaluated_from_matches_header instead, which
    differs only when a message carries two From headers.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads