How We Protect Our Customers

Every spam filter faces the same trade-off. Filter too aggressively, and real messages get lost. Filter too loosely, and advertising and fraud flood the inbox.

We have made our choice, and we will say plainly what it is: to us, a legitimate email in the junk folder weighs more heavily than a spam email in the inbox. This applies with particular force to our business customers' invoices. An invoice that never arrives costs money, trust and, in the worst case, a business relationship.

That leads to a way of working that takes more effort than usual: before a new detection rule goes live, we test its effect against technical characteristics of real mail traffic, without opening any customer mail to do so. If it would catch legitimate business correspondence, it is not put into service; it goes back to the drawing board.

The rules by which email works are set out in documents called RFCs. The name stands for “Request for Comments”, the collection of the internet's technical standards that has been maintained since 1969. Many RFCs are the authoritative technical description of how a protocol is supposed to work. Email itself is described in RFC 5321 and RFC 5322.

Three more recent standards decide whether a sender is genuine. Think of them as a guest list, a seal and house rules:

• SPF, RFC 7208, the guest list. The owner of a domain publishes which servers may send email on its behalf. If a message comes from a different server, it is not authorised.
• DKIM, RFC 6376, the seal. The sending server signs every message cryptographically. The recipient checks the signature. If it does not match, the message was altered in transit or does not come from the stated sender.
• DMARC, RFC 7489, the house rules. Ties the two together and specifies what a recipient should do when the check fails. The domain owner also receives reports on who is sending mail in its name.

Three further standards shape how we operate:

• RFC 3834 governs automatically generated replies. It prevents two systems from sending each other into an endless loop.
• RFC 8461, MTA-STS, requires sending servers that support the standard to deliver over an encrypted connection. Without it, an attacker can switch off encryption in transit, and neither side notices.
• RFC 8460, TLS-RPT, provides reports, from the sending systems themselves, on whether encrypted delivery to us actually worked.

Here we rely not on industry reports but on what we see in our own operations every day. The picture is clear: many senders fail the basic authenticity checks. Many do not sign their mail at all. And quite a few have published a sender record that is technically broken. They believe they are protected, and they are not.

Here is an example that could happen to any practice or firm: appointment reminders or invoices are sent through an external service, but that service was never added to the sender record of their own domain. To every recipient, that mail looks exactly like a forgery.

Behind this lies a problem affecting the entire email landscape: here, too, a noticeable share of incoming mail comes from servers that have visibly not been maintained in years. They use outdated encryption or none at all, they do not support the standards above, and they are an open door for attackers. Anyone sending through such a server makes it hard for recipients to tell their mail from a forgery. Often the people affected have no idea, and that is exactly what fraudsters count on.

For the public at large, this is a risk that goes beyond the individual sender. A hijacked, neglected mail server sends phishing in the name of its legitimate operator, using that operator's reputation and customer contacts. The damage falls on third parties who had nothing to do with the negligence.

We decided not to look away. Mail that does not identify itself is therefore treated more cautiously than mail that does. Not to punish, but to weigh things up: a single missing feature is not enough for us to filter out a message. How we weigh things is set out in section 8.

The Domain Name System, or DNS, is the public record of how a sender reaches us and which rules apply. Everything below can be looked up publicly. We are not giving anything away, and you do not have to take our word for any of it: every entry can be checked with freely available tools.

4.1 Reachability and Delivery Paths

MX   mail.vipmail.app     the primary server
MX   mx2.vipmail.app      the backup server

Two separate servers in two different data centres. If the primary server is unreachable, the backup mail server accepts mail for existing recipients, holds it and delivers it as soon as the primary server is reachable again. As a rule, no messages are lost this way, and the sender does not notice anything.

4.2 Sender Protection

SPF     v=spf1 a:mail.vipmail.app -all
DMARC   v=DMARC1; p=quarantine

The -all at the end of the SPF record is the strictest possible setting. It means: whoever does not send from our server does not send in our name. Many providers use ~all here, which merely expresses suspicion. We do not.

4.3 Encrypted Delivery

MTA-STS   v=STSv1; id=…
Policy    mode: enforce
TLS-RPT   v=TLSRPTv1; rua=…

The DNS record points to a policy that is publicly available at mta-sts.vipmail.app. Its decisive line is mode: enforce. A sending server that supports MTA-STS must use an encrypted connection to reach us. It must not fall back to an unencrypted connection, even if an attacker on the network tries to force exactly that. Through the accompanying reporting standard, we receive reports on whether this worked.

Large mail providers evaluate these records and deliver over encrypted connections. The records are not mandatory, and many mail servers still do not have them.

4.4 Certificate Control

CAA   0 issue "letsencrypt.org"
CAA   0 issuewild "letsencrypt.org"

These records specify that only a single, named certificate authority may issue certificates for our domain. Any other authority must refuse such a request. That makes an entire class of attack considerably harder: one in which an attacker obtains a valid certificate in someone else's name from any certificate authority of their choosing.

4.5 Automatic Setup

Records for automatic setup let a mail program find the right settings by itself. That is convenient, and it also has a security benefit: anyone who does not configure things by hand cannot accidentally set up an unencrypted connection.

On our systems, a message passes through several independent checks. That is deliberate. No single method carries the defence alone, and the failure of one method does not disable the others. Which filtering software we use and how the methods work together, we keep to ourselves. Section 6 explains why.

5.1 Who Gets as Far as the Door?

Before a connection reaches our mail server, it passes through two firewalls. The first sits in the data centre's network. It can neither be reached nor switched off from a compromised server. The second is IPServerSec, our own firewall on the server (section 5.6). Addresses and network ranges proven to be sources of attacks do not even get as far as the mail server's greeting.

5.2 Who Is Knocking?

Before a message is accepted, we check the other end of the connection. Does its address have a valid name record, and does that record point back to the same address? Is it listed in public directories of known spam sources? For this, we query several independent reputation directories. Only the IP address or domain name being checked is transmitted, never an email address or any message content.

If a delivery already looks suspicious at this point, we ask the sending server to try again a little later. A properly run mail server does so without fuss; many bulk senders do not.

We also operate addresses that are not involved in any legitimate business activity. Anyone writing to such an address did not get it from a customer but from a harvested list.

5.3 Is the Sender Genuine?

Every message goes through the authenticity checks from section 2. For senders that are forged particularly often, such as banks, payment services, large platforms and public authorities, we apply a stricter rule: a message appearing under their name must prove cryptographically that it really comes from them. A sender that merely looks plausible is not enough.

A message “from your bank” that carries the right logo and the right greeting but not the bank's cryptographic signature will not reach your inbox with us. Genuine, correctly signed mail from banks and authorities, on the other hand, arrives as normal.

5.4 What Is Inside?

Content analysis is the heart of our defence. It runs entirely on the servers we operate and consists of many modules that can be switched on individually: a message's authenticity and route, structure, links, typography, attachments, patterns of known campaigns and a learning statistical method. Some of these modules we developed ourselves, each prompted by something specific we observed in our own operations. They recognise, for example, when a message claims in its text to be a bank or an authority even though it comes from an unrelated domain, when invoices or customer names are imitated, or when disposable addresses are involved.

Just as important are the modules that work in the other direction. They make sure genuine business mail does not fail because of an unlucky accumulation of harmless features. Clear signs of fraud and malware are still checked for every sender, including long-standing business partners. After all, the hijacked account of a genuine business partner can send fraudulent mail too.

One of these safeguards is our answer to a mistake we made ourselves. A genuine invoice was filtered out because several features, each harmless on its own, had added up unfavourably. Each one had been deliberately given a low weight; nobody had looked at the total. Since then, genuine business mail has its own protection against such accumulations. We mention this here because honesty requires it.

The learning method estimates how likely a message is to be unwanted. It learns from what happens on our servers, and what it learns stays within our infrastructure. Your mail is not sent to any external analysis service, and no outside provider reads your correspondence to improve its model. Many modern filters send message content to a cloud service to improve detection. For a mail server operator in Germany, that can be a serious data protection problem, especially if content ends up in third countries. It was out of the question for us.

5.5 What Is Attached?

Every attachment is scanned for malware. File types used almost exclusively to smuggle in malicious code, such as executable programs, scripts and disk images, are neither accepted nor sent as a matter of principle. Attached HTML files, a common trick for fake sign-in pages, are assessed so strictly that they alone can lead to non-delivery.

5.6 Who Is Attacking? Our Firewall IPServerSec

IPServerSec is our own firewall, and it does more than the term suggests. It monitors the servers around the clock, continuously evaluates the logs of every service and blocks attackers automatically, before a human could even take a look. It does so for sign-in attempts on existing and invented accounts, systematic probing for valid addresses, protocol violations, attempts to abuse our servers as a relay, and attacks on webmail and the administration interface.

Two properties set IPServerSec apart from an ordinary block list. First, it has a memory: an address that draws attention again after a block expires is blocked for considerably longer than the first time. Second, and this is the harder part, it knows the difference between an attacker and a customer with a misconfigured mail program. A customer whose program keeps knocking with an outdated password produces a pattern similar to an attacker's. Anyone who does not distinguish between the two locks out their own customers. For you, this means: a forgotten old password on a second device will usually not lock your whole office out.

For a mail server, attacks are not a state of emergency but everyday business, around the clock. Our aim is for them to end at the firewall, before the mail server ever sees them.

5.7 What You Can Do Yourself

An account is only as secure as its sign-in. Our sign-in interfaces are reachable only over encrypted connections, and two-factor sign-in (2FA) is available for every mailbox. A few things are up to you:

• Turn on two-factor sign-in (2FA). We are happy to help you set it up.
• Use a separate, long password for every account. Our password generator creates one that is still easy to remember.
• If you are missing a message, get in touch.
• We will never ask you for your password by email. Important notices to customers carry a personal proof of authenticity that you can check yourself.

We do not read your mail. All of the checks described here run automatically. Nobody at our company opens customer mail of their own accord, whether to improve detection or out of curiosity. When we develop a detection rule, we work with technical features and headers. The only exception is up to you: if you explicitly ask us to clear up a misjudgement, we look at exactly that one case and nothing else.

We do not pass content on to third parties. Where we query public directories, we only transmit the IP address or domain name in question, never your text, your attachments or your recipients.

We do not name thresholds or filtering software. This document does not say at what score a message receives which treatment, or which software we filter with. Anyone who knows that can design their mailing to stay just below the threshold. That is why we do not disclose this information publicly. That protects you, too. Statutory rights of access and the powers of the supervisory authorities remain unaffected.

We back up in several stages: in different storage locations and at different intervals. At least one stage is kept outside the mail server on a separate system and is updated frequently.

The reason for several stages is simple: every single backup method has a scenario in which it fails. A backup on the same machine does not survive a hardware defect. A backup that runs only rarely loses too much. Stages whose weaknesses do not overlap cover for each other.

We deliberately do not describe the methods in detail here. Anyone who knows where and how an operator backs up also knows what they would have to attack to prevent recovery. That is exactly the first step in modern ransomware attacks: first the backups, then the data. We will not draw that map.

What we can say: for us, a backup counts only once it has been written completely and checked for completeness and integrity. A backup without that proof is treated as invalid, even if it looks complete at first glance.

Customers are right to ask this question, so here is the honest answer.

Normally, quite a lot has to come together. A message is not filtered out because of a single minor feature; it has to fail several independent checks at the same time.

There is one deliberate exception: clear signs of fraud, deception and malware. A message that claims to be a bank, payment service or public authority without coming from there, that appears under the name of a frequently forged sender without a valid signature, or that carries a dangerous file type or an attached HTML document has no business in the inbox, even if everything else looks unremarkable. The complete list of these cases is set out in section 9 of our privacy policy.

Conversely, we take particular care to protect genuine business mail from known senders against misjudgements. The protection modules described in section 5.4 see to that. It is not a free pass: the hijacked account of a business partner can send fraudulent mail too, and we watch for that. Dangerous file types are blocked even from known senders.

If you are missing a message, get in touch.

At this point, we would like to ask for two minutes of your attention.

Picture your own email account. Not today's inbox, but the whole account. Ten years. Maybe twenty. What is in there?

Invoices, incoming and outgoing, with full addresses and amounts. Bank statements and payment advices. Contracts. Dates of birth, addresses and phone numbers of people who trusted you. Sick notes. Job applications with CVs. Photos. The names and addresses of your customers, often built up over many years. Passwords someone emailed you because it had to be quick.

And, less obvious but at least as valuable: the way you write. Your style, your sign-offs, the way you speak to each customer. Enough material to write a message in your name that nobody questions.

Then there is the point most people overlook: whoever has access to your email account can reset your password almost everywhere else. The mail account is the master key. Online banking, inventory management, tax portal, social networks, domain management. Every path leads back through an email address.

Now for the consequences. If your account is taken over and personal data of third parties is affected (and it practically always is), Articles 33 and 34 of the General Data Protection Regulation apply: as a rule, notification of the competent supervisory authority within 72 hours and, where there is likely to be a high risk to the people affected, notification of those people. For a mailbox that has grown over ten or twenty years, that can be a great many people.

And it does not stop at reputational damage. For many businesses, an incident like this can threaten their very existence.

We looked at which email services medical practices use for their communication. We name no providers here, and no practices either. The result did not surprise us, but it stayed with us: many use free mailboxes.

Free mailboxes are built for private correspondence, not for the requirements that apply to handling patient data. Whether such a service is sufficient in an individual case is something each practice has to check for itself. One of the first questions is: is there a data processing agreement at all?

Medical communication carries referrals, X-rays, lab reports, findings and diagnoses. If such data is stolen, the practice generally has to inform the supervisory authority and, where the risk is high, the patients affected as well. And in the worst case, the patient data later turns up on the dark web. Under Article 9 GDPR, health data belongs to the special categories of personal data for which explicitly stricter rules apply.

We described in the previous section what sits in a hijacked mailbox after ten years. For a practice, there is another dimension: access is usually enough to reset passwords elsewhere, learn the private phone numbers of patients and staff, imitate writing style and tone from years of correspondence, and use collected dates of birth to prepare targeted attacks on exactly these people.

All the more important, then, is a safeguard many underestimate: two-factor sign-in (2FA). It is quick to set up and ensures that a stolen password alone is not enough to take over a mailbox.

And by the way: these obligations do not apply only to doctors. Law firms, tax advisers, trades businesses: anyone who processes personal data generally has to report a data breach to the supervisory authority and, where the risk is high, notify the people affected. That damages more than just your reputation. Word gets around.

We are not lawyers and do not give legal advice. But we will put a few questions out there: what does this mean for potential damages claims? And how does a business or professional liability insurer react when the damage can be traced back to the absence of a long-established safeguard? These questions are worth answering for yourself, ideally with your own insurer or legal counsel, and before something happens, not after.

Article 32 GDPR requires protective measures appropriate to the state of the art and to the risk. The state of the art is not what was common ten years ago.

The effort involved is smaller today than many assume. Two-factor sign-in (2FA) is quick to set up. Mail programs can be set up with their own app passwords instead of the main password. Outdated, unencrypted access can be switched off. These are not exotic measures. They are the basics.

Anyone who knows about such obvious safeguards and deliberately does without them must expect uncomfortable questions in the event of an incident: from the supervisory authority, from the insurer and from the people whose data is affected. Take a moment to consider what that means for you. Not for the provider you use. For you.

• Mail servers and backups in data centres within the EU
• A backup mail server in a second data centre within the EU that accepts your mail during an outage and delivers it later
• Several independent layers of checks, from the data centre's network to content analysis
• In-house protection modules against fraud, impersonation and malware
• Dedicated protection for genuine business mail, so it is not filtered out because of harmless coincidences
• Transport encryption that we enforce for senders that support it; mail programs connect only over encrypted connections
• IPServerSec, our own firewall, monitors around the clock and blocks attackers automatically
• Two-factor sign-in (2FA) available for every mailbox
• Multi-stage backups, every backup checked for completeness and integrity
• Nobody reads your mail without your explicit instruction

We did not build all this to keep it to ourselves. We are proud of what we have learned and built over the past few years, and we are convinced that email today should be secured the way this document describes.

Hence this offer, which is explicitly open to everyone who does not host with us yet: if you feel uneasy about your own communication, if you do not know which of the measures described above your current provider has in place, or if you simply want a second opinion, talk to us. That goes for medical practices as much as for law firms, tax advisers, trades businesses, mid-sized companies, associations and individuals.

We review existing configurations, take over your live mail traffic, usually without any noticeable interruption, and then host it in data centres within the EU. A quote costs nothing and commits you to nothing. If our form rejects your request, simply write to postmaster@vipmail.app.

Anyone who offers email accounts to third parties today provides a telecommunications service and is therefore subject to special requirements and obligations. We take these obligations seriously and put them into practice. This document shows how.

vipmail.app is a service of intelligent piXel GmbH, Enzianstraße 4a, 82319 Starnberg, Germany, HRB 207679.