Security

How your mail is protected, stated specifically rather than in adjectives.

4. How it is protected

Exactly what is configured today — no more:

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.exe pattern, which is reported as a *type refusal* and never dressed up as 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 — there is no default, and we will not invent one. If the Boss ever configures 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. That is the whole point of a scanning engine and there is no version of it that sends less. If that ever happens, this 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 and this document will never call them that.

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, so the cost is on the record before that decision.

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 a complete classifier on its own, not a degraded one, and 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 — not one byte, not one request.

Exactly what is sent to the Anthropic API when that tier is on. This is the complete list; there is nothing else in the payload:

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, and we are not going to pretend they are only "rule names".
`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.

Say the cost out loud. 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 (§4A) is never classified at all. If HAMANI ever enables this tier, this policy and docs/AU-LEGAL-HOSTING.md §4 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 §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 (§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. If a certification matters to you, we would rather lose the sale than claim one we do not hold.