Client-side filters only work when the app is open, which is why your phone shows an unsorted inbox. Server-side rules run on delivery, once, for every device. A rule builder and a raw Sieve editor in the webmail, rules written in other clients preserved, and the plus-addressing trick that needs no rules at all.
Client-side mail rules are a trap. You set up a beautiful sorting system in the mail app on your laptop, and then you look at your phone and the inbox is a wall of everything, because the rules live in the laptop and the laptop is shut. Worse, the rules only run when the app is open, so "when I get to my desk on Monday" is when your Friday mail gets sorted.
Server-side rules fix this by moving the logic to where the mail actually arrives. The sorting happens on delivery, once, before any device sees the message. Every client you own then agrees, because there is nothing left to disagree about.
This post is about how that works at email.eu, plus the small trick that makes rules dramatically more useful: giving out addresses that sort themselves.
Filtering at email.eu happens on the server, in the standard language for exactly this job. It is called Sieve, it is an internet standard rather than a vendor feature, and it has been the way serious mail systems do filtering for two decades.
A rule is the shape you would expect. When mail arrives matching something, file it here, or flag it, or send an automatic reply, or send it somewhere else entirely. The important part is when it runs: at delivery, on our servers. Your phone sees the message already in the right folder. So does your laptop, whether it was open or not.
Because it is a standard rather than something we invented, your rules are yours in the same way your mail is yours. They are text, in a documented language, readable and portable. Nobody has to reverse-engineer a proprietary rule format to move them somewhere else.
This is the same machinery our own features are built on, which is a decent sign that it is real rather than a checkbox. When you set up an external forward, what happens underneath is a generated rule of exactly this kind. We deliberately keep ours on a separate hidden account so that the rules we generate can never collide with the rules you write. Your script is yours alone.
In the webmail, under Settings, there are two ways in.
There is a rule builder, the ordinary one: when a message matches this, do that, filled in with dropdowns. That covers what most people want, which is a handful of rules that file things by sender or subject.
And there is a raw editor, for writing the rule language directly. That sounds like a footnote and it is the reason this section exists: it means the ceiling is the language itself, not whatever a form designer thought to expose. If you are coming from a setup where you had built something genuinely elaborate, you are not being asked to rebuild it inside somebody's simplified UI.
Because the underlying protocol is a standard and stays open on our servers, you can also manage rules from outside our webmail entirely, with any client that speaks it. Rules written elsewhere are recognised and preserved rather than quietly overwritten the next time you open the editor here, which is the failure mode that makes people distrust a rules screen.
The vacation responder sits alongside both.
Here is the part that needs no editor at all.
Take your address and add a plus and any word before the @. If you are you@yourcompany.eu, then you+newsletters@yourcompany.eu and you+conference@yourcompany.eu are both you. Mail sent to them lands in your inbox exactly as before. You did not create anything, you did not configure anything, and there is no limit to how many you can invent.
What makes this useful is that the tag survives the whole journey and is visible in the message. So:
It costs nothing, works today, and is the highest-value thing in this post for most people. It is also completely standard, so the addresses keep working anywhere you take your domain.
One honest caveat that applies everywhere, not just here: a small number of web forms reject a plus in an email address, because whoever wrote the validation did not read the specification. When that happens you are stuck using your plain address for that one service, which is annoying and not something any mail provider can fix from their side.
The out of office reply is a filter rule wearing a different hat: when mail arrives, and I have not already replied to this person recently, send this text. It runs on the server, which is the only sensible place for it, because the entire point is that it works while your laptop is in a bag.
One thing worth saying, because people go looking in the wrong place: it lives in your mail settings, not next to your calendar. It is a rule about mail rather than about time.
Same engine again for the related things people ask about: filing by sender, flagging anything from a particular customer, quietly discarding a newsletter you cannot unsubscribe from.
Most people need two rules and plus-addressing, and are then done for years. That is a perfectly good outcome, and it is why we lead with the addressing trick rather than the rule language.
The people who will care about the rest are the ones migrating from a setup where they had built something elaborate, and who want to know it survives the move. It does, because we did not invent a private rule format that only works here. If you are in that position and want to check your specific setup before you commit, ask us and we will look at it with you rather than guess.