Security
How it is protected
What is configured today:
- Encrypted at rest. The mail storage bucket uses S3-managed server-side encryption (SSE-S3). The database table uses DynamoDB encryption at rest with an AWS-managed key. The send queue uses SQS-managed server-side encryption.
- Encrypted in transit to us. The mail bucket and our notification topics require TLS — unencrypted requests are refused. The API is HTTPS only.
- Not public. The mail bucket blocks all public access.
- Backed up. Point-in-time recovery is enabled on the database table.
- Not deletable by accident. Both the mail bucket and the database table are set to be retained even if our infrastructure stack is torn down.
- Scanned. Amazon SES scans inbound mail for spam and viruses before it reaches you; a virus or spam failure is routed to a quarantine folder rather than your inbox.
- Least privilege. Each part of the system is granted access only to the specific resources it needs.
- Rate limited before authentication, so credentials cannot be attacked at speed.
Attachment scanning — what it does, and what leaves
The local layer below runs on your inbound mail today, in addition to Amazon SES's own spam and virus scan. The optional third-party engine is a slot that is not configured — see the second bullet.
There are two layers, and they are deliberately told apart:
- Local checks, which never send your file anywhere. These run inside our own system with no network call at all. They refuse the published EICAR anti-malware test file, files whose first bytes are a Windows, Linux or macOS executable, files whose declared type is executable or script content, and filenames with an executable extension — including the disguised
invoice.pdf.exepattern, which is reported as a type refusal, not a malware detection. - A third-party scanning engine, which we do not have. Our system has a slot for a commercial scanning service. No such service is configured today. If we ever configure one, then for an attachment the local checks did not already refuse, the entire file is uploaded to that service, together with its filename, its declared content type and its size. If that ever happens, our Privacy Policy will be updated to name the provider and the country it operates in before a single attachment is sent to it — and it would be an APP 8 cross-border question if that provider is overseas.
The verdict rule. A result is one of three things: clean, infected, or unscanned. unscanned exists because the failure that actually infects someone is a system reporting "clean" when nothing looked. With no engine configured, an attachment the local checks did not refuse comes back unscanned, never clean — and the same is true if a configured engine is slow, unreachable or returns something we cannot read, or if the file is over the size ceiling (10 MB by default), in which case it is not sent to the engine at all. Local checks are not antivirus.
Automated spam and phishing classification, and the AI tier
The offline classifier below runs on your inbound mail today and sends nothing anywhere. The AI tier is off unless an Anthropic API key is configured — and by default no key is set, so nothing about your mail leaves our systems. This section describes exactly what the AI tier would send if it were ever switched on.
Again two layers:
- The offline classifier, which sends nothing anywhere. No key, no network, no third party. It looks at sender display-name spoofing, a Reply-To that points somewhere other than the sender, link text that lies about where the link goes, punycode and mixed-alphabet lookalike domains, links to bare IP addresses, high-abuse domain suffixes and urgency / credential-request / advance-fee wording. It is what runs when no AI key is set.
- The AI tier, which is off unless a key is configured. With an Anthropic API key set, each inbound message produces one call to the Anthropic Messages API (
api.anthropic.com). With no key set, nothing leaves.
Exactly what is sent to the Anthropic API when that tier is on. This is the complete list:
| Field | What it is |
|---|---|
subject | Your message's subject line, verbatim, up to 300 characters. |
from | The sender's display name (to 200 characters) and email address (to 200). |
replyTo | The Reply-To address, if the message had one. |
linkHosts | Hostnames only — up to 25 — from the links in the message. Never full URLs. The path and query of a link are where a per-recipient tracking token lives, and a tracking token identifies the reader, so it never leaves. |
localFindings | Up to 12 of the offline classifier's own findings, in words. These quote evidence from the message — the matched phrase, a link's visible text, the sender's display name — so they are message content too. |
bodyExcerpt | A bounded plain-text excerpt of the message body, 2,000 characters by default, with every URL inside it reduced to [link:hostname]. Setting the limit to 0 sends no body at all. |
That excerpt is your correspondent's message content, sent to a third party outside Australia. Reducing URLs to hostnames does not change that: whatever else was written in the first 2,000 characters — names, figures, addresses — goes with it. That is why the tier is off unless a key is deliberately set, why the limit is settable to zero, and why a private mailbox (our Privacy Policy, section 4A) is never classified at all. If HAMANI ever enables this tier, our Privacy Policy must be updated first, because sending message content to a US-based API is a cross-border disclosure question, not a configuration change.
No message is ever failed by a classifier. If the AI call times out, errors, is refused, is cut off or returns something that does not match the required shape, the offline verdict is used instead and it says so in its own reasons. The model is also never allowed to invent a suspicious link: only links genuinely present in the message survive into the result.
And what is not true, stated plainly:
- An ordinary mailbox is not end-to-end encrypted. We hold the encryption keys. That means HAMANI is technically capable of reading stored mail — see our Privacy Policy, section 6 for the rules we work to. There is now one exception, and exactly one: a mailbox you have deliberately put on the zero-knowledge private tier (our Privacy Policy, section 4A), where we hold ciphertext we cannot open. Unless you have done that, for the mailbox you did it to, this bullet stands.
- Mail in transit between mail servers is not guaranteed to be encrypted. SMTP encryption is opportunistic: it happens when the server at the other end supports it. That is true of all email everywhere, and we do not require TLS on inbound mail.
- We hold no security certifications. We are not ISO/IEC 27001 certified, we have no SOC 2 report, no IRAP assessment and no Essential Eight maturity assessment.