Most people assume their mail provider reads their messages. Many do, for advertising, for building profiles, or for training models. ITProMail is built on the opposite assumption: the provider has no business reading the contents of your mail, and the system is designed so that it does not need to. This article explains that position, where it has practical limits, and what the limited inbound filtering we perform actually involves.
Why a mail host should not read content
Email is a record of who talks to whom, when, and often about what. The content is the most sensitive part, but the metadata is useful too, as discussed in Metadata is the leak. A host that reads content holds everything in one place. That creates legal exposure, a target for attackers, and a temptation for insiders. Every additional system that can read plaintext is another system that can be compromised, subpoenaed, misconfigured, or quietly changed.
There is also a trust problem that policy alone cannot fix. A promise not to read mail is only as strong as the code and the people behind it. Architecture is the more reliable guarantee. If the host never needs plaintext for a feature, then a host that starts reading plaintext has to change its code to do so, and the scope of what it can see is set by what it was built to do.
Encryption at rest is not the same thing
ITProMail encrypts mail at rest. That protects the storage media: a stolen disk or a leaked backup yields ciphertext. It does not protect against an operator who can reach the running service, because when an IMAP client asks for a message, the server has to decrypt it to send it. Server-side encryption answers a different question from end-to-end encryption.
If you need the host to be unable to read a message at all, the mail has to be encrypted on your side before it reaches the server. That is what PGP provides, with keys that you control. The practical trade-offs are covered separately. PGP protects the content but not the envelope: subject lines, headers, sender, and recipient remain visible to the mail system.
What inbound filtering involves
Some processing of inbound mail is unavoidable. A mail server that accepts messages from the open internet has to decide whether to accept them. Some of those decisions use data that is not message content at all: the connecting IP address, the sending domain, and whether the message passes SPF, DKIM, and DMARC checks. Those checks are described in SPF, DKIM and DMARC explained. Authentication results come from message headers and DNS records, not from reading the body.
Beyond that, abuse filtering necessarily looks at some content in order to block malware and spam. Anti-malware scanning inspects attachments, and spam classification looks at features of the message. It would be inaccurate to say that a host which filters inbound mail never looks at content. The honest description is narrower:
- Filtering runs on inbound mail as it arrives, before delivery to the mailbox.
- Its purpose is to stop abuse before it reaches your inbox, not to build a profile of your messages.
- Its results are used to accept, reject, or flag a message. ITProMail has no advertising and no tracking.
- Sending mail is different. A message you send travels to the recipient's server over TLS in transit, and after that the receiving side decides what to do with it.
What you can verify
Do not take any of this on trust. Check the parts you can check.
- Confirm the connection uses TLS. For IMAP, the server listens on port 993 with implicit TLS. For submission, use port 465 or 587 with STARTTLS. Run
openssl s_client -connect imap.itpromail.com:993to see the certificate and negotiated protocol. - Read the authentication headers on mail you receive. Mail from a domain with DMARC in place will show a
dmarc=result in its Authentication-Results header. - Export your mailbox at any time from Account > Export, in mbox format, or with any IMAP tool. Your data is not locked in.
- Read the summary on the security page and the security checklist.
The limits
No hosted service removes all trust. A host can change its code, a legal order can compel an operator to act, and a compromised server can expose data in memory. The design goal is to minimise what the host can see, and to keep the remaining exposure narrow and documented. For content you need private against the host, use end-to-end encryption on your side. For everything else, the protections are encryption at rest, short log retention, the TLS requirement, and a business model that does not depend on reading your mail.