Trust model

Privacy and URL handling

Understand what sc extracts, what it fetches, and where the privacy tradeoffs are.

SpamHost.Report is a static website. It does not accept spam uploads or run a public analysis API. It doesn’t gather any information about you, including analytics.

The sc tool itself runs in your environment. It statically extracts URLs from plaintext and HTML bodies. In HTML, it looks at link-like attributes, srcset, inline style attributes, <style> blocks, and meta refresh tags.

What sc does not fetch

sc does not fetch remote images, scripts, stylesheets, forms, iframes, or other external resources referenced by a message.

Attachments are intentionally out of scope. The tool does not process links from attachments.

Recipient identifiers

Abuse reports include the original spam message as evidence. That message may contain the email address of a real user in headers, body text, unsubscribe fields, or other message metadata.

Spammers also commonly embed recipient-specific identifiers in links, redirect URLs, tracking pixels, and image URLs. Those identifiers may be enough for the sender or a downstream service to map the report back to the targeted email address, even when the address is not visible in the URL itself.

Review generated reports before sending them. If your environment requires redaction, do that in your reporting workflow before forwarding evidence to abuse contacts.

Network requests

The normal analysis path uses RDAP and ARIN HTTP APIs to find abuse contacts for IPs discovered in Received headers and hosted links.

Message-derived network requests are limited to configured shortener expansion. When a listed shortener is found, sc follows up to five HTTP redirects and reports the final non-shortener host instead of the shortener.

This can leak an access to the shortener service and may reveal information about the recipient or analysis system. Keep the list narrow or set it to [] if you want completely passive URL analysis.

Some tracking systems encode their destination directly in the URL. sc may decode known wrappers offline without contacting the tracking service. Undecodable known wrappers are skipped rather than fetched.

XARF evidence size

When XARF is requested, each report includes the original RFC-822 email as message/rfc822 evidence with a base64 payload, byte size, and SHA-256 hash. XARF evidence items are capped at 5MB; larger requests fail with xarf_evidence_too_large.