jarland

No, I went straight to trying to shame them on Twitter. The part where I said "We’ve tried to talk. @Apple just stops responding once they realize what we’re asking" was just a joke, you got me.

There is no defined process for obtaining it. If you'd like to tear down that statement into little pieces and dissect it, I recommend getting a new hobby because it's not that interesting.

MXroute doesn't go around threatening US companies with EU law from Texas. As for your requirement for evidence, this situation does not require your approval unless you work for Apple and can offer some help in the matter. The tweet you are critiquing is me (owner of MXroute) attempting to gain Apple's attention to get what Fastmail and that EU user have obtained. I'll continue doing what I'm doing, if that's alright with you. I'm well aware of the situation and what others have done. What I need at this point is eyes on the prize. I'll get what I'm after, but a public statement that I currently cannot get what I'm after is entirely appropriate for the avenue I've chosen to do so.

It's a mistake to assume that I'm merely flailing my arms chaotically and generically playing the role of Karen.

Having friends inside of Apple that provide you with something no one else can obtain is a fairly decent definition of favoritism.

You cannot send Push notifications to the stock iOS Mail app no matter how hard you try. They can. There are functions inside of iOS that are made better because of this (auto copied 2FA codes, for example).

The stock Mail app for iOS does not support JMAP.

The stock iOS Mail app does not support JMAP and therefore it has no relation to Push notifications for the stock iOS Mail app.

This is exactly why we put this as a forbidden use case in the MXroute policy:

“Deceptive use against third party services by creating multiple email accounts to pretend to be multiple users of their service”

Because if you want to maintain a good reputation with people, you don’t facilitate people taking advantage of them.

It varies. It likely is an exaggeration for you, but for someone else it isn’t. It only needs to target a few domains to act as a DDOS. Rejecting invalid recipients reduces spam scanning overhead. It’s very significant at scale, for someone managing enough domains to see it.

The problem seems to be that while many domains don’t see this behavior, it seems random which ones do. Having the catchall in place when someone finally does target your domain like this seals the deal: Every one of the 16,000 recipient addresses that were accepted were just added to a list of working email addresses to be sold to spammers for the next 15 years. One hour to ruin your domain, and maybe it never happens to you, or maybe it happens to you tomorrow.

I’ve seen it go down like this at least a few hundred times in the last decade. Safe to say I’ve managed email for a few domains during that time. Enough to say it doesn’t happen to most people, but the ones it happens to usually end up having to disable their catchall or buy a new domain.

As an admin of shared mail servers you often have to base protections and actions on the worst of events, as those are the ones that threaten your infrastructure.

Feel free to open a support ticket about that and request that I evaluate any such 30 minute delays. If it’s the Friday server and you’re referring to inbound, mitigation has been applied while I work on the long term fix.

We (MXroute) maintain low queues (high queues set off alarms, literally). Funny detail, I actually have our combined mail queues as a widget on my phone: https://files.freesocial.co/f.php?h=0fyHTzMz&p=1 (don’t judge me, I like iOS this week)

We have excessive resources as well as our own IP ranges. Any delays are most likely related to someone else. Can’t send someone email faster than their mail server accepts it. Happy to answer a support ticket about it but all of our mail queues are human audited every few hours.

Best wishes for you and your startup, we need more good people out here.

Edit: There is one exception being one older server that is experiencing a bug specific to cPanel, which is mitigated presently with a final resolution in progress. That’s just sysadmin stuff.

There's some good feedback in there and I appreciate it!

Whatever you decide, I'm here for you at MXroute and would love to have you on board. I understand your concerns and I wouldn't say anything to invalidate them, the burden of choice is yours and I'm merely here if you need me <3

I appreciate your recommendation. I'm no friend to intelligence agencies, but I don't want to necessarily put myself out there as a competitor to something like the old Lavabit. I'm not looking to be a victim of the US government any more than I want to see my customers victimized by them.

This has been my position for a while as well. We even saw last year the revelation that the CIA had been in Switzerland:

https://www.washingtonpost.com/graphics/2020/world/national-...

It's definitely a false sense of security to assume that being on one side of a particular border increases your security. There may be degrees of truth to it but there's no "if your data is here, no agency will ever come for it." When protecting the contents of your data is important, the largest workload should be on sender and recipient. The protocols they decide to use, the encryption they choose for their content, etc.

The problem is that a very significant number of email clients don't because it's not part of the open standards that they're implemented for.

It's a very tight line to walk, when I intend to offer these lifetime packages and run a company that outlives me. That's why you'll see the price rising on it. I'm trying to find the impulse buy threshold and exceed it to stay on mission. These plans can only fill small unused corners of already profitable servers. Anything more is irresponsible on my part.

And that's totally cool. I think a lot of alternate perspectives around this focus on proprietary implementations, and my focus revolves mostly around open source and licensed software. MXroute isn't a software vendor, and this confuses a lot of people because there are a lot of mail providers out there that are. Google and Microsoft are easy examples.

How do you track the name without tracking the password itself? The IMAP standard doesn't provide a function for this. You'd have to log the password used and do it that way. It'd be hard to implement such a thing with the base protocol without adding a security concern.

Then again I'm not a software developer, I'm an admin and hope to be hiring a dev this year. MXroute works mostly on open source or licensed software, with a heavy focus on custom in-house configuration being around the outbound relays, as the initial focus of MXroute was based on getting emails to their recipients, no matter the cost. These days, that's increasingly difficult and time consuming for a lot of people (IP reputation, etc).

Appreciate those notes! Will be redoing a lot of the documentation very soon, and will keep this in mind.

Apologies for the bad first impression. This is somewhat intentional. MXroute was originally created for sysadmins who don't need bells and whistles, and just need their email to get to its destination without fussing with IP reputation and things like that.

You know the old saying "If you want God to laugh, tell him your plans." Well, we became very popular with end users that weren't sysadmins at all. Still convinced that we could offer high deliverability at low cost while slowly improving UX to fit a new type of customer, we entered a bit of a dark age where support tickets were going unanswered for months. Because our pricing was meant to be extremely competitive and completely ditch the whole "per user" pricing that plagues the market space, and we were becoming more popular with end users, we were overrun with basic support questions and pre-sales inquires.

The first thing we did was cut out pre-sales inquiries. With enough sales occurring organically without advertising, and with pre-sales inquires having a high correlation with cancellation requests (because our UX wasn't designed for the end user who happened to be the most likely to have a huge list of questions before purchase), we decided that we weren't going to let our overhead (and as a result, our prices for existing customers) suffer at the hands of something that wasn't generating revenue.

The second thing we did was to cut back on direct support and focus on publicly available information for troubleshooting. Ideally, we'd funnel customers or prospective customers into our community forum and community chat, where they could ask questions and help each other with answers, and build up a list of questions/answers that were given in the language of the customers, to help reduce repetitive support requests. Because we found that 15 customers might ask the same question in 15 different ways, by having a community resource where the questions and answers fit those different scenarios, we could do more there than we could by automating responses to keywords.

Leveraging these community resources assisted us in building customer facing documentation and automation rules for our direct line of support, which in turn allowed us to begin leaning back into more directly available support with automation and documentation to fall back on.

Now, we're back offering more direct support after having weathered the storm caused by the unintended shift in our customer base. This is of course assisted by our documentation, and articles are regularly added to address common questions. We're routinely adding automation to auto reply to repetitive questions, and taking those repetitive questions to form better onboarding processes that intend to prevent them.

Time and time again I saw that companies were getting lost in the overhead required for providing support. You'd see in my employment history that I've been on the front lines of that with support at HostGator and DigitalOcean. I always had a vision of how to scale support in a way that would not require the seemingly inevitable steps of outsourcing, followed by selling the company. But only on MXroute did I have the direct opportunity to implement my vision. It hasn't been a flawless process, but I do think that the present result is some of my best work. Of course, as with anything, opinions may vary.

Hey drcongo. Jarland from DigitalOcean here. Truthfully, we would have to talk about individual cases to provide a detailed answer. Being aware of who you are and knowing how the details of these cases compare in relation to you, I would say that you already do everything that you should to prevent being caught up in the kind of experience that has you concerned.

I realize that is vague, but it's a bit of a difficult thing to discuss without exposing private data. If I so much as say "Just don't do X" then I'm effectively saying Client A did X. Tough waters to navigate.

I hope that helps a bit at least.

Toss me an email, I'll see what I can do :)

The answer depends on a variety of factors, but in general, when we're alerted to something that could be a violation of our Terms of Service, we attempt to engage with customers. In some cases, we may take actions against the resources running against an account and a vast majority of the time, there is a grace period before any permanent action is taken. If you have questions about specific cases, we recommend contacting our support team directly.

I'd love to chat with you. If you have some time, send an email over to jdonnell@digitalocean.com and let's talk. I promise nothing but honesty, transparency, ideas, and maybe a few laughs :)

Hey friends! My name is Jarland and I'm on the support team at DigitalOcean. We do have a number of fraud and abuse algorithms, and when we are alerted to potentially fraudulent activity, we take appropriate action, which includes notifying and communicating with individual users. I also want to confirm that we are fully compliant with GDPR.

I should have added to that: We're not actively trying to collect anything under $1, so to us a $0.15 balance is not something we need you to pay right now.

That sounds, to me, like snapshot billing. Any chance you have any snapshots on the account? Toss me an email at jdonnell@digitalocean.com or open a ticket with our support team, we'll take a look :)

Hey friend,

I'm sorry that you've had a bad experience, but we can help. Our support team will gladly increase that limit for you on request.

On the stories that you read, I hear you. It's a tough situation because I don't want to discount anyone's story. What I do want to point out is that there are two sides to every story, and in such a relationship one party has the duty of protecting privacy of the other. Sometimes we make mistakes and we need to correct it. Sometimes what we do upsets people when we work to protect our customers from those who would seek to abuse our platform. Abuse of our platform lowers quality of service for everyone, and that is why it is our duty to manage that. Each story will have it's own variables, and I'm happy to discuss anyone's situation with them personally.

If you have any questions or there is anything I can personally help with, please feel free to reach out at jdonnell@digitalocean.com.

Jarland

I'm sorry you feel that way. We always try to work with our customers to resolve disputes in the best way possible. There are two sides to every story and we do respect the privacy of our customers. If you would like to talk about anything specific that you are concerned about, I'd be happy to chat at jdonnell@digitalocean.com.

I'm sure I'm around here somewhere ;)

You can open a support ticket any time and we'll do our best to answer any questions you have. You can also email me at my name here @digitalocean.com.

I think it's absolutely appropriate to sit down and talk about ways that we can prevent this, both in the short term and long term. I don't think it's as simple of a problem as some might suggest, because you've got to balance expected behavior, a reasonable expectation of convenience, and added security measures.

I don't think you can make a proper decision where you're only looking out for protection, or only looking out for convenience, or only looking out for expected behavior. I think you have to mesh all of these items together and make a change that addresses each item, and I don't think that's necessarily a one day discussion. Certainly security does come at a cost of convenience, and that is okay, but it is important not to toss convenience aside as something not worthy of consideration.

So yeah not trying to be vague, my position is not with engineering or security but with the support team. I do think we need to talk about this, and conversations are taking place, but I don't honestly have the ability to say "Yes we're going to implement _____ within ____ days" or something like that. At least not today.