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).
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.
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.
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.
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).
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.