Microsoft BS

Durham, NC, Thu, 24 Oct 2019 20:46:08 -0400

I have already spent too much time trying to get Microsoft to unblock my email servers, which do not seem to have a reputation for spam anywhere and don't even have enough of a sending record to be rated yet by Brightmail. ...but Microsoft sends me this, 24 hours after I request an unblock:

Dear Woozalia Staddon

We have completed reviewing the IP(s) you submitted. The following table contains the results of our investigation.

Not qualified for mitigation
165.227.176.23; 45.55.148.146
Our investigation has determined that the above IP(s) do not qualify for mitigation.

Please ensure your emails comply with the Outlook.com policies, practices and guidelines found here: #^http://mail.live.com/mail/policies.aspx.

To have Deliverability Support investigate further, please reply to this email with a detailed description of the problem you are having, including specific error messages, and an agent will contact you.

Regardless of the deliverability status, Outlook.com recommends that all senders join two free programs that provide visibility into the Outlook.com traffic on your sending IP(s), the sending IP reputation with Outlook.com and the Outlook.com user complaint rates.

Junk Email Reporting program (JMRP) When an Outlook.com user marks an email as "junk", senders enrolled in this program get a copy of the mail forwarded to the email address of their choice. It allows senders to see which mails are being marked as junk and to identify mail traffic you did not intend to send. To join, please visit #^http://support.msn.com/eform.aspx?productKey=edfsjmrpp&page=support_home_options_form_byemail&ct=eformts.

Smart Network Data Services program (SNDS). This program allows you to monitor the 'health' and reputation of your registered IPs by providing data about traffic such as mail volume and complaint rates seen originating from your IPs. To register, please visit #^http://postmaster.live.com/snds/.

There is no silver bullet to maintaining or improving good IP reputation, but these programs help you proactively manage your email eco-system to help better ensure deliverability to Outlook.com users.

Thank you,

Outlook.com Deliverability Support

I already included the error message in my original problem report, where it says "copy and paste any error messages":

This looks to me basically just like the big players trying to keep out the competition. They're blocking unknown servers by default, making it basically impossible for anyone without an IT department (aka the resources to deal with this level of hoop-jumping and or possibly twist some arms or grease some palms) to offer reliable delivery to Microsoft addresses.

Google is nowhere near this bad, but they sometimes reject messages from my servers too. So does ProtonMail, and some Yahoo relays do as well.

I'm not sure what an appropriate response is here, other than the obvious one of destroying all capitalism and requiring companies over a certain size to be controlled by the people they supposedly serve; working on that.

Microsoft email bureaucracy elitism anti-competition

show all 10 comments

Paul Hosking

Thu, 24 Oct 2019 21:24:30 -0400 from Diaspora

I don't think this is anti-competitive practices. It's collateral to dealing with fraud. Your domain doesn't have any email authentication methods set, does it? I think you're going to want at least a MX record for each mail host and a SPF record for them. That might, maybe, be enough? Dunno. I'm not a mail services wonk.

There's some details in that document you linked at...

https://glockapps.com/blog/email-authentication/

For examples... see what MS is doing...

paul@newt:~$ host -t mx outlook.com outlook.com mail is handled by 5 outlook-com.olc.protection.outlook.com.

paul@newt:~$ host -t txt outlook.com outlook.com descriptive text "google-site-verification=0iLWhIMhXEkeWwWfFU4ursTn-_OvoOjaA0Lr7Pg1sEM"outlook.com descriptive text "v=spf1 include:spf-a.outlook.com include:spf-b.outlook.com ip4:157.55.9.128/25 include:spf.protection.outlook.com include:spf-a.hotmail.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com ~all"outlook.com descriptive text "google-site-verification=DC2uC-T8kD33lINhNzfo0bNBrw-vrCXs5BPF5BXY56g"

Woozle Hypertwin

Sat, 26 Oct 2019 14:10:56 -0400

So it's objecting to something about the return address, and not the IP address at all? That's completely inconsistent with the error message:

host
    outlook-com.olc.protection.outlook.com[104.47.14.33] said: 550 5.7.1
    Unfortunately, messages from [165.227.176.23] weren't sent. Please contact
    your Internet service provider since part of their network is on our block
    list (S3140). You can also refer your provider to
    #^http://mail.live.com/mail/troubleshooting.aspx#errors.
    [VI1EUR04FT047.eop-eur04.prod.protection.outlook.com] (in reply to MAIL
    FROM command)

I do have MX and SPF set up for my main return-address domains. If the error message had indicated a problem with the return address, I would have double-checked that I was sending the message from one of those, but it's saying something completely different.

Paul Hosking

Sat, 26 Oct 2019 18:02:01 -0400 from Diaspora

First off - I could be entirely wrong here. Setting this stuff up isn't what I usually do. ;)

And I'm assuming that Microsoft's penchant for crap error messages and logging is applying here. ;)

Having said that... the domain sending email to the O365 environment is hypertwins.com, right?

paul@newt:~$ host -t mx hypertwins.com hypertwins.com has no MX record

paul@newt:~$ host -t txt hypertwins.com hypertwins.com has no TXT record

I could see O365 looking at emails claiming to come from the hypertwins.com Domain as suspicious since the Domain itself doesn't really point at what is legit.

Or at least - that's my interpretation. I could be way off.

mathew

Sun, 27 Oct 2019 16:06:28 -0400

Bounces go to the envelope sender address, not the From: address in the mail. So both domains need to have valid MX addresses if the e-mail is legitimate.

Woozle Hypertwin

Sun, 27 Oct 2019 20:43:19 -0400

It was actually woozalia.com; I just used hypertwins.com for the trouble ticket.

Points to consider:
1. MS had no trouble sending email to hypertwins.com or woozalia.com.
2. Nobody else has either; I can reliably use those domains as return addresses e.g. when I get e-receipts at stores.
3. Therefore: it shouldn't matter if the return address has an MX record or not. Nobody else cares.
4. Nothing was mentioned in MS's error message about MX records or the return address being issues, so MS doesn't care either -- or else they're deceptively giving an incomplete/inaccurate description of the problem.

So either we have MS being unusually persnickety about certain details and deceptively not giving accurate information about what is needed to fix the problem, which supports my original charge of anti-competitive behavior, or my original hypothesis -- that they're blocking unknown addresses by default -- stands, which also supports my original charge.

Your theory actually makes it worse, because that would mean they're also giving email senders invisible hoops to jump through -- the kind of thing that a well-funded IT department might have had the time and expertise to tackle, but which I kinda don't.

Paul Hosking

Mon, 28 Oct 2019 00:26:33 -0400 from Diaspora

I'm amused that I find myself in a position of defending Microsoft. So let's just pretend that I'm not really doing that. Instead - it's just me helping out an acquaintance. I think. Maybe.

So the reason I'm doing that is that though I don't set up mail systems... I do deal with (among other things) email fraud. There's millions of dollars involved. It's noisy. It's pervasive. And sometimes it's caused geeks to be less-than-friendly trying to deal with the onslaught (trying to deal with blacklist services is the stuff of legends). It's not because they're making money forcing you to use their service. It's because Bad Actors spin up a dozen fraud machines faster than you can or I can spin up a hobbyist mail server... and they'll look like us unless we do things that they don't want to (in theory - its amazing what fraudsters will do sometimes).

So having said that...

It's the receiving domain / email server that makes use of various anti-spam / phish / fraud mechanisms. Not the sender. So sure - they're OK sending mail out. But when it comes in to their system, they're going to start looking for signs of phishiness.

I don't want to defend the terseness of the error message (and I'll note again that IMHO MS is just generally horrible when it comes to error messages in everything that they do... absolutely horrible). But I get the sense that the error message is less of a specific call-out and more of a generic "computer says this looked suspicious." Given that... and that the documentation you linked to (assuming it's trustworthy) specifically mentions SPF records... and I know MS checks that stuff... and that you've already checked whether the IP shows up in a blacklist... I'm going to guess that's where you'd have to look to get your mail servers to look trustworthy.

Yeah. Sucks. But the game has changed since to good 'ole days of spinning up an email server on a dial-up and dealing with spam messages selling greencards and herbal snakeoil.

mathew

Mon, 28 Oct 2019 11:01:10 -0400

Of course nobody has trouble sending e-mail to your domains. They believe their e-mail is valid so they're not going to spam-filter it.

I assure you, every sane e-mail admin checks validity of envelope sender to some level. It's harder to fake than the From: address so more likely to catch spam. Most will also require a valid From: address. I enforce both of these restrictions even for e-mail servers I run inside my employer's Intranet. MX checking of envelope addresses is a standard antispam feature; check out amavisd if you want to implement it yourself.

Stefani Banerian

Sat, 07 Mar 2020 22:37:44 -0500 from Diaspora

at a minimum these days you need to set up DKIM and SPF, and i've added ARC (openarc)

Woozle Hypertwin

Sun, 08 Mar 2020 09:30:53 -0400

I've done SPF; DKIM looks difficult, not sure how to make it happen... and I'd never heard of ARC. [makes notes on what needs doing...]

Stefani Banerian

Sun, 08 Mar 2020 14:38:05 -0400 from Diaspora

i know some mailers are also using dnssec i have not gotten there yet