Google does not respect SRS, do not forward email to Google

- Posted in Uncategorized by

Originally when we launched in 2013, we asked users not to forward to major services like Google. They don't like it, they don't want to receive it, and they block us because you do it. Fast forward to today and only one thing has changed: We've gone out of our way to accommodate your forwarding needs as best we can. The other side, however, still doesn't want it or like it. Although we've done our best to help, and will continue to do so, we will also continue to advise against the practice because of that simple fact: They don't want it, and they will fight back against it.

Today we bring you another reason not to forward. We've been reviewing emails rejected by Google, and we've found a strong theme. Here is a sample from our logs:

Jun 7 09:46:35 Server22734-me postfix-110/smtp[21776]: 61D21CBD0559: to={removed}@gmail.com, relay=gmail-smtp-in.l.google.com[74.125.21.26]:25, delay=1.7, delays=0.65/0.01/0.33/0.68, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[74.125.21.26] said: 550-5.7.1 Unauthenticated email from ymail.com is not accepted due to domain's 550-5.7.1 DMARC policy. Please contact the administrator of ymail.com domain if 550-5.7.1 this was a legitimate mail. Please visit 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about the 550 5.7.1 DMARC initiative. a17si725522ywa.360 - gsmtp (in reply to end of DATA command))

This was a forwarded email from ymail.com. However, if you look above this in the logs, you'll see that we did everything right:

Jun  7 09:46:34 Server22734-me postfix-110/qmgr[8285]: 61D21CBD0559: from=<SRS0=kR35do=UG=ymail.com={recipient}@{client_domain}>, size=63260, nrcpt=1 (queue active)

We used SRS, and nested "ymail.com" in the sender with the client domain at the end. But Google still rejected it for DMARC, because SRS is not about updating the actual "From" field in the headers. Therefore, Google has chosen to respect DMARC over SRS. Google does not want your forwarded emails. When forwarding to them, you absolutely must forfeit some of the email you receive, and it is 100% in their hands.

We will continue to do our best to support your forwarding habits, but please understand that you have stacked the deck against yourself if you've chosen this path, and that any resulting lost emails are a direct result of your decision to do so. Please be careful with the decisions you make, we can only do so much to help you to force another email provider to work how you want it to.

 

Promotions!

- Posted in Deals by

For some time now MXroute has gone without any promotions. Today we're opening a brief window in which two promotional offers are once again available for purchase. There will not be many of these, so jump quickly if you want them. No guarantees that they will return.

BF2018
100GB Storage
Unlimited Email Accounts
Unlimited Domains
Order here ($15/year or $25/2years or $30/3years)

Lifetime10GB
10GB Storage
Unlimited Email Accounts
Unlimited Domains
Lifetime* service - one payment
* Lifetime means the lifetime of MXroute
Order here ($100)

 

Learning as we go

- Posted in News by

Learning how to scale out a support system in a small business is one of the most challenging things that I have ever done. MXroute support wait times are high, and the workload grows at a rate which exceeds my personal ability to answer the questions. I can look at this as a failure and retreat, or I can see it as an opportunity to learn and improve.

When scaling out a support infrastructure, it's easy to learn the ways not to do it. You experiment, observe the result, and quite often your theory doesn't hold up to reality. As discouraging as failure can be, no one articulated the opportunity it presents better than Thomas Edison:

I have not failed. I've just found 10,000 ways that won't work.

There in lies the opportunity. Each failure is simply a lesson in what not to do. Here's what we've learned doesn't work:

  1. A staff-created Knowledgebase.
  2. Exposing common questions prior to accessing the contact form.
  3. Using Slack to siphon off quick questions and prevent tickets.

So once again we're trying a new strategy. We're going to change the support workflow in pieces. I'll go over the rough plans for that now.

This is to allow you to ask the questions in your own words. Perhaps even duplicate questions because one of the existing ones may not be worded in a way that it looks like it could answer your question. This creates a community-assisted database of material that can be used to expose better answers to questions prior to opening support tickets. That brings us the next step.

  • Second, we're going to launch a chat bot.

This is a heavily trained bot that will be intended to help you identify the right answers to your questions without ever needing to speak to a human.

Now, we value human support just as much as you do. We also recognize that having a human answer every question is simply not a viable strategy at our scale. The more questions we can answer without a human, the more available we can be when you actually do need to talk to us. It's about maximizing the quality of human interactions by automating the repetitive ones.

Rest assured that MXroute support is not dead, we're just struggling to find the right answer. We've found a bunch of ways that don't work, so we're that much closer to the ones that do.