Legal

Privacy Policy

Last updated 20 September 2026

This policy is about the personal data that passes through Humainbox when it filters your website contact form submissions. Most of that data is not yours and it is not ours: it belongs to the people who filled in your form. That fact shapes everything below.

1. The short version

• You are the controller of the form submissions. We are your processor.
• We store the raw message compressed on object storage, plus a set of parsed fields.
• Message content is cleared when your retention window runs out — 30 days unless you choose otherwise, never more than 90, the same on every plan and for held and delivered mail.
• Messages the cheap rules cannot decide may be sent to a large language model provider for classification. Message content leaves our infrastructure when that happens. You can turn it off.
• After a purge we keep only per-rule decision records: rule names, numeric weights, short reasons, timings. No content, no personal details.
• We do not sell personal data, and we do not train models on your message content for other customers.
• Message data is stored and processed in the European Union. If you leave classification on, message text is sent to a sub-processor outside it — and you can switch that off per account.
• We hold no security certification. We are not going to pretend otherwise.

2. Our role: processor, not controller

A visitor fills in a form on your website. You decided to publish that form, you decided what it asks for, and you decided why you wanted the answers. That makes you the controller of the personal data it collects.

Humainbox receives those submissions because you pointed the form at an address we generated. We filter them and forward them according to settings you choose. We do not decide what the data is for. That makes us a processor, acting on your documented instructions.

Two practical consequences. First, your own privacy notice needs to tell your visitors that a third-party filtering service processes their submissions on your behalf — we cannot give them that notice, because they have no relationship with us. Second, when one of them asks to see or delete their data, they will ask you, and we help you answer (section 13).

The one area where we act as controller in our own right is the data about you — your account, your users, your billing (section 16).

3. Whose data this is

The people whose personal data we process on your behalf are the visitors who submit your form. We have no relationship with them, we never contact them, and we never market to them.

Because a contact form is free text, we cannot control what a visitor types into it. A form that invites sensitive disclosures will produce sensitive data in our system. Humainbox is not designed or hardened for special-category data, and you should design your form accordingly.

4. Exactly what we store

Rather than describe categories vaguely, here is the actual list.

The raw message

The complete email as received, compressed, on object storage. It is the only place attachments exist. It is purged on the retention schedule.

Parsed fields

• sender name
• sender email address
• subject
• message body
• arrival time
• message size
• character set
• attachment count (a number, not the attachments)

The resolved reply address

The address a reply should go to, and — deliberately — a record of which source it came from: the Reply-To header, the message body, or the From header. Where the address came from is itself a signal about whether a message is genuine, which is why we keep it.

Authentication results

The authentication results written into the headers by the receiving mail server, and which server wrote them. We copy these rather than re-derive them, and we record the source so a result can be trusted or discounted appropriately.

Rule decision records

One row for every filtering rule that ran against the message, holding the rule name, a numeric weight, a short human-readable reason, and timing. These contain no message content and no extracted personal details. See section 8 for what happens to them later.

Delivery records

• destination address
• delivery status
• attempt count
• the provider’s message id
• any error returned

Configuration

Your account, the users in it, the recipients you have configured, your threshold, your retention period and whether external classification is enabled.

5. Attachments

Attachments are forwarded with the mail and are not read. The file is copied out of the stored original into the message we send. Nothing unpacks, parses or indexes it, no text is extracted from it, and it is never part of what is sent for classification — the classifier receives the message text and nothing else.

We record how many files there were. The files themselves exist only inside the raw stored message and disappear with it when that message is purged; they are not copied into the parsed record.

Where the mail provider's own scanning flags a submission as carrying a virus, its files are neither stored nor forwarded. That verdict is formed at the provider before we receive the message — it is the only opinion about a file's contents anywhere in this service, and it is not ours.

6. Why we process it

We process form submissions for one purpose: to decide whether each is a genuine enquiry or automated spam, and to forward the genuine ones to the recipients you configure. Everything we store exists to serve that purpose, to let you review a decision you disagree with, or to let us diagnose a delivery failure.

We act on your instructions, given through your account settings and through your use of the service. We do not process this data for our own purposes, with the single narrow exception described in section 15.

7. Retention and purging

Message content does not sit here forever. Retention is a window, not an archive:

• message content is cleared when the window runs out — 30 days unless you choose otherwise, and never more than 90, on every plan;
• the same window applies to held and to delivered mail, because both are your enquiries;
• it is configurable per account, so you can always shorten it.
• a message still waiting on a decision from you is left alone until you have made it.

A purge removes the raw stored message, its attachments and the parsed fields — the sender name, the address, the subject, the body. There is nothing left to read afterwards.

Humainbox does not delete anything as part of filtering. A held-back message is still there, still readable in the panel, for the whole of its retention period.

8. What survives a purge, and why

After message content is purged, the per-rule decision records are retained. We want to be explicit about this rather than let you discover it.

Each retained row holds only:

• the name of the rule that ran;
• the numeric weight it contributed;
• a short human-readable reason;
• how long it took.

No message body. No subject. No sender name or address.

A row may also carry what the rule matched — a phrase, a count of links, the top-level domains a message linked to. None of it names anybody, and none of it is enough to reconstruct a message. When a workspace is closed it is removed entirely, along with the link to the account and to the message, leaving only the rule, the weight, the reason and the timing.

The reason we keep them is straightforward: it lets the service keep getting better at filtering without keeping the personal data it learned from. We can see which rules fire together, which produce false positives against your threshold, and which have stopped earning their place — long after the messages themselves are gone. Retaining the decisions rather than the data is a deliberate design choice, and we would rather explain it than quietly rely on it.

9. Sub-processors

We use a small number of sub-processors. Described by function:

Cloud hosting and object storage

Runs the application and holds the compressed raw messages.

Email infrastructure

Receives the submissions sent to your Humainbox address, and delivers the mail we forward to your recipients.

Large language model provider

Classifies messages that the cheaper deterministic rules cannot decide. Section 10 covers this in full, because it deserves more than a line in a list.

Public information about a sender's company

When an enquiry that is not spam comes from a business address, we look at what is public about that address's domain — its own home page, its DNS records, and its registration date from the domain registry via rdap.org — and show it in your panel beside the message. Only the domain name is used for this; no message content and no personal address leaves. None of it is added to the email we forward.

The named list, as of 20 September 2026. Customers are told before any of it changes.

There is no separate object storage vendor: the raw messages are kept on the same machine that runs the application, in Frankfurt.

10. The language model, stated plainly

This is the part of the system most likely to matter to you, and the part most easily buried in a list of vendors, so we have given it a section of its own.

Turning it off

There is an account-level option to switch external classification off entirely. With it off, no message content is sent to the model provider; messages are decided by the deterministic rules alone. Filtering is less accurate in that mode. If your own commitments to your visitors do not permit sending their words to a model provider, use that setting.

What is and is not sent

Only what the classification needs: the message content and the signals around it. Not your account identity, not your recipient list, not your configuration, and not attachments.

11. Where processing happens

The application, the database and stored message files are in the European Union. That is where your account lives and where message content is kept.

Classification is the exception, and we would rather name it than bury it: when it is switched on, message text is sent to a large language model operated by a provider in the United States. That switch is per account and it is yours. Turned off, the gate keeps running on the signals that do not require it, and no message text leaves our systems.

Where data is transferred outside your region, those transfers rely on appropriate safeguards, including standard contractual clauses with the sub-processor concerned. The specific transfer mechanism for each named sub-processor belongs in the sub-processor list and in the data processing agreement, and must be confirmed by counsel before launch.

12. Security measures

These are the measures actually in place:

• Encryption in transit. Connections to the application and between components are encrypted.
• Encryption at rest. Stored messages and database contents are encrypted on disk.
• Access logging. Access to systems and data is logged.
• Strict tenant isolation, enforced at the data layer. Queries carry an account scope. A query that arrives without one fails loudly rather than quietly returning another account’s rows. Isolation is a property of how the data layer is written, not a convention developers are asked to remember.
• Fail-open delivery. If a component fails, the message is delivered rather than lost. This protects against losing an enquiry; it is a safety property, and it means an internal failure can let spam through.

13. Data subject requests

Because you are the controller, requests from your visitors come to you, not to us. We support you in answering them.

• Deletion. Deletion by email address across stored messages is supported. Ask us and we will remove that person’s messages from your account’s storage.
• Access and rectification. We assist within the technical limits of what is stored — we can produce what we hold for a given address, and correct it.
• Erasure and the decision records. The per-rule records described in section 8 contain no personal data, so there is nothing about that person left in them to erase.

If a visitor contacts us directly, we will not act on their request ourselves. We will tell them to contact you, and let you know it happened.

14. What we do not do

These are commitments, not aspirations.

• We do not sell personal data. Not to anyone, in any form, under any label.
• We do not use your message content to train models for other customers.
• We do not market to your visitors. The people whose messages we process never hear from us. We do not add them to any list.
• We do not share message content across accounts. The one thing that can be shared is described next — and it is a hash, never content.

15. The campaign hash

Spam arrives in campaigns: the same message, lightly personalised, hitting many sites at once. Recognising that is one of the most useful signals available, so there is one narrow thing we share across accounts.

We strip the personalisation from a message, take a one-way hash of what remains, and may compare that hash across accounts to recognise a repeated campaign. A one-way hash cannot be turned back into the message it came from.

Message content is never shared across accounts — not the body, not the subject, not the sender. Only the hash.

16. Data about you, our customer

For your own account we are the controller. We hold your account details, the users in it, the recipients you configure, your settings, support correspondence and billing records. We use them to run the service, to bill you, to provide support, and to send service notices such as a change of sub-processor.

You have the usual rights over that data — access, correction, deletion, objection, portability — and can exercise them through the contact page. Portability needs no request at all — export everything yourself from Settings → Data & privacy, which also gives you what you need to answer a request from someone who wrote to you. Reaktör Teknoloji Tic. Ltd. Şti. is established in the Republic of Türkiye, so the supervisory authority for its own processing is the Turkish Personal Data Protection Authority (Kişisel Verileri Koruma Kurumu). Where we process message data on your behalf you remain the controller, and the authority for that processing is the one that supervises you.

Our lawful basis for holding your account details is the contract between us — we cannot run the service for you without them. For billing and accounting records it is a legal obligation: tax and commercial law in Türkiye require them to be kept, and we keep them for ten years from the end of the financial year they belong to, which is that requirement rather than a choice of ours. For counting visits to the marketing website it is your consent, given or refused at the banner and changeable at any time. None of it affects message data, whose retention you set yourself and which is described in full in section 7.

17. The free contact-page check

Anyone can paste a web address into the check at /check without an account. We fetch that one page, once, from our own servers, identifying ourselves honestly in the request, and we read the domain's public DNS. The answer is shown on screen and not kept: there is no account attached to it, no email field on the page, and no record of the address afterwards.

Because the request is made by us rather than by the browser, the site being checked sees our servers and not the person who asked. The check will not reach anything that is not on the public internet — addresses resolving to private, loopback or link-local ranges are refused, and redirects are re-checked rather than followed blindly.

18. Businesses we approach

Separately from the service, we research businesses we might write to and keep a short record of each one: the domain, the company name as their own site writes it, the address of their contact page, what is publicly visible on that page — which form builder it uses, whether a CAPTCHA is present, what its DNS says — and a draft of a message to them.

That record holds no personal name and no email address, and nothing in it comes from anywhere except pages the business has published itself. Nothing is sent automatically: a person reads each draft, edits or discards it, and writes from their own mail client. If you would rather we held no record of your business, write to [email protected] and we will delete it.

19. Cookies

Three strictly necessary cookies, plus Google Analytics only if you accept it. No advertising and no cross-site tracking either way. Analytics never runs inside the application — the pages you see when signed in carry message identifiers, and those are not ours to hand to anybody. The Cookie Policy lists them individually.

20. If something goes wrong

If we become aware of a personal data breach affecting data we process for you, we will notify you without undue delay and give you what you need to meet your own obligations as controller: what happened, which data was involved, what we have done and what we recommend. As controller, the decision about notifying a regulator or affected individuals is yours.

We will tell you without undue delay and in any case within 48 hours of becoming aware. Write to [email protected] to reach us about an incident, at any hour — it goes to a person, not a queue. A data processing agreement may set a shorter deadline; it may not set a longer one.

21. Changes to this policy

We will update this page when the system changes, and the date at the top will change with it. For anything material — a new sub-processor, a change to retention, a change to what is sent for classification — we will notify account holders in advance rather than rely on you noticing.

22. Contact

For privacy questions, a data processing agreement, an EU region request, or help with a data subject request, use the contact page. For anything about privacy or your data, write to [email protected]. It reaches a person rather than a queue, and it is the address for an access, correction or erasure request as well as for an incident.

Reaktör Teknoloji Tic. Ltd. Şti. is established outside the European Union and the United Kingdom. Where a service is offered to people in those territories a representative there is generally required, and we will appoint one before the service is sold into them — this page will name them when we do. We have not appointed a data protection officer; if that changes, this page will name them too.