u/mxroute

My Rabbit R1 sat in a bin for quite a while. I loved the device, in theory, but in practice it didn't really do anything for me. I had even put a sim card in it, but it never worked and I just walked away quietly.

I found it today. Charged it, updated it, and holy hell. Sim card works. Now I can connect it to OpenClaw and Hermes, and even control Claude Code sessions remotely?

I just wanted to give a digital high five for the Rabbit team. Truly incredible work. I've never been so impressed by the growth of a device over time. I absolutely love working with AI to help me organize my life, and this thing went from "cool but not really usable" to "I'm ordering a new one because the battery has been so disrespected that it can't possibly maintain the maximum battery life originally possible."

If you installed webmail.mxroute.com as a progressive web app on your mobile device, you may benefit from force closing the app and reopening it. The "Reconnecting" problem is solved, finally.

While we're still planning native mobile apps, for now this webmail as a PWA is kind of a big deal to me. Right now, this is the only way I check my mail on my phone. I want it to be flawless. At least in my Samsung phone, it's pretty damn close now.

If you've never used a progressive web app before and this makes no sense to you, PWAs can be installed on mobile devices in a way that operates a lot like a native app, while being "just a website." Google "how to install PWA on iOS/Android" if you're unclear on how to make use of it.

Okay, maybe not YOURS. But just about every contact form these days takes information like this:

- Name
- Email address
- Message

Some contact forms reply like this:

"Hi, name. We received your message. Your message was:"

Even among the ones that don't, they'll still often say:

"Hi name, we received your message."

Now imagine someone inputs this:

Name: Free crypto at cryptoscam.xyz
Email address: randomvictim@gmail.com

So you sent randomvictim@gmail.com this message:

"Hi Free crypto at crytoscam.xyz, we received your message."

This is how your contact form is exploited to send spam, from you, to anyone that your malicious website visitor desires. And you wonder why your emails land in spam folders. This is why.

The fix is simple: NEVER, under ANY circumstances (not even with a captcha), should you EVER send ANY string input by a website visitor to an email address entered by the website visitor. And if you only email them to yourself, your contact form needs to be sending to your MXroute-hosted address, not sent to or forwarded to any major email provider that you need inbox delivery with. Because no one cares about the intention of your contact form, if you send spam messages to major email providers you are the cause of reputation issues.

One key thing about MXroute: We're looking out for this. We will call you out on it. We know how to tell that it's happening, and we'll test your contact form ourselves to verify it. Then we'll block your outbound email until you fix it. Because your reputation matters, and so does everyone else's.

I don't like saying this, but I've committed to honesty and transparency regardless of the cost. There was an edge case across our platform where inbound email was silently discarded based on a user's very specific spam filtering configuration. It was the same oversight that DirectAdmin made for years, and I overlooked it in exactly the same way when implementing spam filter configuration in panel.mxroute.com. This covers less ground than you think it does. It's a very specific scenario, and it almost entirely caught actual spam (and only typically caught non-spam when a user set a domain to a reject score that was too low, which to be fair the panel does warn them about).

If you set one domain to reject at one score (the threshold in panel.mxroute.com), and then proceeded to set a second domain to a lower score, a subset of inbound emails would be silently rejected. It worked like this:

If the inbound email scored under the EasySpamFighter (DirectAdmin package) reject score, above the user's SpamAssassin required_score, and below the the domain's high_score, the email would be silently discarded. The problem is that each change of a spam score under a single user account would push that score as an update to high_score (reject threshold) and required_score (SpamAssassin spam threshold), and required_score is one value for the entire Linux user account, not a per domain value. I did this for other reasons, but I overlooked this edge case.

The fix for this was to bypass required_score altogether. As of right now, until we finish deploying our new spam filtering system, we have no function for "is identified as spam by SpamAssassin, but should be delivered." And it's not consistent with our language, our language in the panel is clear: This is the reject threshold. So that's what it should do, and it should do exactly that per domain as instructed by the customer in the panel. That update has been pushed to the servers, and now behavior consistently aligns with what the panel says it does.

I know what you're thinking: How do I know what's happening at any given time with spam filters?

Like most email services you just don't. Microsoft, Google, Yahoo, none of these give you any insight into when they have rejected an email. But we're working on it, and I'll give you an update on that while I'm here:

I'm still working on rolling out our new Logs feature in the panel, so that you can finally have 100% insight into what is happening on the mail server for your account. It's a much larger job than I imagined, because I want you to be able to quickly search and pull any data that you want, regardless of the size of your account. In the first iteration of it, larger accounts would timeout because we were drawing correlations from exim, ZoneMTA, and in some cases the mail.baby API (mail.baby being our vendor falback relay for emergency use or to prove that delivery failure isn't related to our IP reputation) to create the full life cycle for every email at query time. Now we're doing those correlations in advance on the ClickHouse server and trying to fully perfect what is basically turning a complete mess into an easily digested package that gives you as much or as little information as you'd like (quick summary + raw logs). I'm being a bit too much of a perfectionist on this, I don't want it to feel like a half-baked feature on release.

If you browse to Settings and then Filters, you'll find that server-side filtering is now part of the new webmail.

Because I know you're going to ask: We do not allow filters to be used as email forwarders, conditional or otherwise. We do intend to restore this functionality once I feel that it is properly restricted and altered to function in a way that doesn't inherently decrease everyone's reputation.

I'm going to be honest with you guys, some of these posts I make are meant for me to link to later when someone makes a claim or asks a specific question, and I like the public discussion format of it as opposed to "one more item buried in a FAQ page."

A concern often cited is that potential customers are afraid, based on stories that have been passed around, that their account might be too quickly terminated without chance for them to plead their case. I've always said up front that I do not make such decisions unless I am faced with information that does not require a discussion to reach an absolute conclusion. So I'm going to go over two cases that occurred today as a bit of an example of cases that you don't hear about:

Case 1:

Customer of reseller connected SalesHandy (self described "cold email" platform, cold email objectively being the industry definition of spam, the entire reason spam folders exist) and started out with two emails that were clearly unsolicited marketing email. Caught early, low volume, no damage actually done yet. Reseller's customer was suspended. Logs show personal connection to another one of reseller's accounts, suspended that one for now as well. The second account shows direct connection to reseller's brand. Reseller was asked questions via ticket to determine if this connection means that the "cold email" behavior requires action against the reseller account to properly resolve. As no actual damage was done to our platform, I'm willing to hear the reseller out and I'm willing to go as far as unsuspending both accounts if an agreement is reached.

Update: Second account was a misunderstanding, unsuspended. First account willing to unsuspend, pending user agreement not to send cold email. Reseller is clear to continue operating, and the relationship is better understood now.

Case 2:

Reseller asked for deliverability report for customer domain. While performing the audit for them, we noticed what appears to be a heavy trend of unsolicited mass email that could be argued as marketing-adjacent (financial benefit being there, but not literally selling a product/service directly). While the volume isn't low, there is no evidence of damage yet, and it is my opinion that we may be able to talk this through. Waiting for reseller to make argument in customer's favor, and I'm willing to reconsider my first read on this account's activity.

For the most part, the only time anyone hears about events that take a negative turn is when they've been 100% identified as a threat, they knowingly and intentionally abused our systems while causing significant damage, and it was clear that they knew what they were doing. No one writes a review and says "They suspected me of being a threat to their platform's reputation, and then we came to an agreement." But it happens all the time. It's easy to see us as unreasonable when you're only hearing stories from people who are upset about getting caught trying to cause harm to us and, by extension, our customers. The real life day to day is everything that happens in between, everything you don't see.

It has come to my attention that we're not doing enough to communicate to new customers the lengths we go to, to make sure that the email you send through us reaches its destination. Just as a quick drive-by here on Reddit, I'd like to cover it real fast:

If you send an outbound email, the first thing we do is of course try to deliver it. If the email is rejected for a reason that can't be solved (invalid recipient, your email content specifically was rejected, etc), we bounce it back to you. But if we're not sure, if we think it even might be related to our IP reputation, we try again from different IPs in our network. If the rejection continues, and we're still not certain that it isn't related to our reputation, we send the mail to our backup relay partner mail.baby, who then attempts to do the same thing with their own network (helping to rule out that the recipient is blocking our network specifically). Only then do we bounce the email back to you and say "Sorry, they're not going to accept this email."

Perhaps I've done a bad job at communicating this as we've grown. This is our primary strength as a mail provider. We will walk through the fires of hell to hand deliver your email if we have to, metaphorically... unless...

This blog post is about the history of how we get here, where we are, and what needs to change this year to provide users with the basic experiences that are widely considered to be fundamental to providing an email service.

...and I would do it again too. Today we met a crypto spammer who tried to send over 5000 crypto spam emails in just 35 minutes. All to a list of Gmail accounts that was so bad it could only have been purchased from someone who tried to scam them out of money for a list of email addresses. You couldn't scrape a list this bad, and you couldn't generate a list that looked like it. They were refunded and told to "get the fuck out and never come back."

If you find yourself wondering if you could ever end up on the wrong side of this from a false positive, let me ease your mind right now. The customer admitted, in a prior support ticket, that the email account and sender IP belonged to them. The emails (100% clear in the logged subject line) were advertising the launch of a crypto coin that matched the website their domain points to. This wasn't a mistake. This wasn't a "rogue employee." This wasn't a customer of theirs. This was our direct customer who confessed in advance to their spam campaign.

I make these posts to serve as continual warnings to people who are considering signing up for MXroute. MXroute is an email provider for real, good people who aren't trying to spam or scam others. Builders, businesses, people who want control over their email. These are the people that are welcomed at MXroute. Protecting your chance to see inbox delivery is a primary goal here, and it's a goal that creates a lot of enemies. Because there are a LOT of people out there who would gladly screw you over to run their next rug pull scam.

Consider this to be yet another ornament dangling on the scarecrow at our front door.

1. One webmail option for users on witcher.mxrouting.net is down, because it just can't help but practically crash the box right now with complete insanity: https://status.mxroute.com/incident/23

2. The wednesday.mxrouting.net server is getting a hefty DDOS, working on mitigation. https://status.mxroute.com/incident/24

And this is me looking up at the sky right now: https://www.youtube.com/watch?v=bIZoVO8ZyyQ

Hey friends,

I assume it's been noticeable, but the new webmail has a Feedback button in the top right area once logged in. Please be sure to use it, it'll rate limit you to prevent anything that would be deemed excessive, so just have at it.

The first iteration was shaped into my dream webmail client. The thing is, I don't use a lot of the features that you guys do. I rarely use contacts. My calendar is elsewhere. I have no use for drafts. There are just so many things that I don't see through your eyes. That's what that Feedback option is for.

As you're well aware, using AI to weed out excess work that doesn't need a human hand, but suffers under unintelligent automation, is a big deal to me. It's my dream come true. Here we found yet another perfect use case for that big LLM workstation on my desk. It takes all of your feedback, generalizes it, writes it to an sqlite database, and then I can query it and immediately see what the top remaining complaints or suggestions are. And with that power over the feedback you send, I am able to shape the priorities around your problems, hopes, and desires.

What I'm driving at here is that MXroute is growing up, and you guys are shaping it into the service you want it to be. The webmail is just one part of it, that feedback trend is going to extend wider as we go. So not only do you get affordable email hosting without the per user cost that everyone else colludes on (I know they don't, but it "feels" like it, therefore it's truthiness). You also get to shape this into everything you want it to be. It may not be fast, but I hope you see the continual progress.

Thank you all for the feedback you've sent thus far. A new deploy is going out right now to address a bunch of the bugs that I just couldn't see, because I didn't have your specific email accounts in hand.

Hey friends,

I just wanted to crowdsource a question to you all, in case any of you happen to have any experience. It's a small question for me, but probably a much larger answer, so I get if your answer is "I'm not answering that for free." Anyway, here goes:

Based on experience you may have, what is unique about dealing with customers from Turkey, and based on what you know, what might I be doing wrong when communicating with customers from there?

Quite simply, there is obviously a cultural difference that I don't understand. Because support interactions with normal people from Turkey are more likely to devolve into garbage than a ticket with a spammer from Florida. I don't know what I'm doing wrong, short of just giving them whatever they want whenever they ask. So maybe there's something I can learn.

Featuring: lies, incompetence, and fake vacations

Even if it was a real vacation and everything was automated to kick off over the weekend... deploy shit on Friday, dip out on Saturday, expect some shit on Monday. Everyone knows this 😂

While there are still plenty of things that I want to do here, the in-house webmail is now fully released at https://webmail.mxroute.com . Custom branding instructions are here: https://docs.mxroute.com/docs/branding/custom-webmail-branding.html

Contacts/calendars have been imported from the old webmail.mxroute.com so there's no need to migrate them yourself. Users using the CalDAV on the old webmail.mxroute.com previously have received an email indicating a change they need to make to any CalDAV clients, but honestly it's not that many users.

There is a feedback form in the webmail client where you can submit any requests, bug reports, etc. This will be used to set further development priorities.

Someone recently said that I like to brag about terminating customers. It's not that. I really hate terminating customers, because it means they engaged in activity that spends the reputation that the rest of you built. These posts aren't actually celebration, though I may frame them that way from time to time. The real reason is this:

If you are going to send unsolicited marketing email, spam, from our platform I do not want you as a customer. I do not want your money. I do not want to know anything about you. Inbox delivery is earned, and while I can't promise everyone that they'll see it, I can promise that I'll do everything in my power to make sure we're not the reason your emails land in spam folders.

This is me washing off the scarecrow. Because it gets dirty out there in the weather. Sometimes it seems like people don't see it. Here it is, in all it's glory.

I've had enough of this, I'm adding this as a quiz item on the order form:

"Account farming is when you create a bunch of aliases, email addresses, or use a catchall for the same purpose to create a bunch of accounts on third party platforms while pretending to be multiple users of that platform. This kind of behavior has no place here, and it paints our service as being associated with high risk. Do you agree not to engage in this kind of behavior with MXroute?"

If my options were:

1. Live in a mansion with these people's money.

2. Eat ramen noodles in a one bedroom apartment with the rest of you.

It's #2 every time. Apologies for the continually growing order form quiz. These people trying to devalue our platform just increase in number every day.

Complete rewrite from previous tests: https://webmail.mxapps.net

Initial security audit complete and while there's a few "this should be better" points, and the same with features (ex. mobile looks like ass), there's nothing here that should give you pause when logging into it. Note that Calendars and Contacts operate from dav.mxroute.com, providing you (hopefully) perfect sync with other applications.

As with webmail.mxroute.com, your MXroute server is derived from your MX records. It expects your mail to be pointed directly to us, or else it won't know how to login. There are reasons I chose this over other paths, there's an obvious way that seems simpler at a glance but runs into deep seated issues that can't be dealt with in a day...or year. We'll revisit that in time, but if webmail.mxroute.com works for you, so should this.

Just "some" of the known issues:

- Mobile view is terrible

- Conversation threading picks up bad messages

- Messages not always marked read

- Notifications come through while you may have to refresh a few times to actually see the new email

Don't worry, I'm kidding. Probably.