Security model
SendProofs makes outbound requests to URLs found in emails you upload. That is a responsibility, so the request path is deliberately narrow. Everything below describes behavior enforced in code today — not policy intentions.
Before any request is made
- Protected-action classification. Links recognized as unsubscribe, sign-in, reset, verification, invitation or order/purchase actions by URL and link-text patterns are never requested — at upload and again on every redirect hop.
- Private and internal networks are blocked. Hostnames are DNS-resolved first, and every resolved address must be public. Loopback, RFC 1918 private ranges, link-local, carrier-grade NAT, multicast, reserved and documentation ranges are refused for both IPv4 and IPv6, as are
localhost,.local,.internaland.home.arpahostnames. - Only standard ports. 80 for http, 443 for https — nothing else. URLs with embedded credentials are refused outright.
While a destination is checked
3 redirect hopsmaximum, every hop re-screened and recorded
2 s / 5 s / 10 sconnect, read and total time budget per resource
64 KBresponse-body cap; larger bodies are truncated and flagged
0 retriesone attempt per destination, HEAD-first with a bounded GET fallback
- Requests connect to the address resolved during the safety screen — no second DNS resolution that could be switched underneath the check.
- TLS certificate verification is on; a failed handshake is recorded as Broken, not retried insecurely.
- Every request identifies itself as
SendProofs/0.1. Your recipients' addresses are never involved — only the URLs from your own test email. - There is no browser and no JavaScript execution, no cookies, no stored credentials, no proxies, and no attempt to bypass rate limits or bot protection. Destinations that refuse automated access are reported Inconclusive — not forced.
Account security
Workspaces are isolated per account, uploads require an authenticated session with a single-use submission key, and oversized upload requests are refused at the HTTP layer before processing. Application-level encryption keys are required for the service to boot at all — see data handling for what is stored and how.
What we do not claim
- No compliance certifications are claimed — there is no SOC 2 or ISO audit to point to, and we will not imply one.
- Properties of the hosting environment that we have not independently verified — geographic residency, backup schedules — are not asserted here.
- Found something? Write to vmarcetic@bytecode.hr and we will respond as fast as we can.
Read the data lifecycle next
What is kept, what is never kept, and what is redacted.