Microsoft’s Colonization of Email Services

Date: 20230319

Intro

I spent ages investigating why MS was blocking my mailserver from putting email to accounts hosted by them and learned that this was a much wider problem then just me. Under the pretense of “security concerns” I discovered that Microsoft is breaking the Internet up into islands of email connectivity of which they are one of the major gate-keepers. My testing herein against Microsoft’s published mandatory connection standards to their email servers will reveal their “security concerns” as a false pretense employed to artificially restrict trade in mail services. And there are serious anti-democratic & free-speech implications. True, MS is a corporation, but unlike a government, the scope of their operations is supranational and so exerts greater influence than (nearly) any single government could. And Microsoft’s operations are controlled by a few unelected billionaires & fund managers. Recent history illustrates that technology billionaires are inclined towards restricting communications to only speech which aligns with or amplifies their own personal biases.

How is Microsoft breaking the internet into “islands of email connectivity”? Under the pretense of “security” and anti-spam measures, they are refusing connections from competing email services, small organizations & individuals hosting their own mailservers which meet their published mandatory security configurations . The result is that only large mail services providers such as Google which could legally challenge their anti-competitive behaviour are able to transfer mail to Microsoft hosted email accounts. There’s no discussion, nor appeal of Microsoft’s decision to refuse connections to their mailservers for those who cannot legally challenge their army of lawyers. The result is islands of email connectivity with Microsoft enforcing the borders of their island of BILLIONS of email users scattered across the globe. Presently, maintaining a stranglehold on mailservices is the basis for blocking connections to their mailservers rather than imposing or enforcing any nefarious ideology. But that might not be the case in the future as corporations increasingly impose their own social agendas which again, serve to impose the personal biases of the billionaire who controls the corporation on their customers.

I’m not some random guy who’s unfamiliar with email services: I architected & executed an email insourcing project for a £45 billion global company moving their mail services back in-house from a global third-party IT services provider. I configured my first mailserver back in 2002. And in addition to being a technologist, I’m also a former Police Officer who also considers the legal & social dimensions of technologies which I’m involved and I find Microsoft’s corporate colonization of parts of the Internet to be anti-democratic, anti-free-speech and most likely in breach of anti-competition laws.

1. Test Criteria: Microsoft’s Published Standards

I’ll test my mailserver’s compliance with Microsoft’s published standards for connections to MS mailservers from third parties which details (5) standards: General (policy), Legal, Technical, Authentication & Reputation Management. The first two relate to commercial content- spamming- while the 5th “Reputation Management” only provides visibility into error codes logged by MS if they already are allowed to connect. I’d need to first be able to connect to be banned for reasons of violating MS’ anti-spam policies and relatedly they can’t show me error codes if they are stopping me at their front door. Thus, I’m left with just (2) of the (5) connection standards that I can test for my compliance with: “Technical” & “Authentication” recapitulated below for ease of reference when reviewing the test data which follows.

3. Technical Guidelines: Emails sent to Outlook.com should comply with the applicable recommendations listed in the documents below (some links are only available in English).

  • (c) In addition, email servers connecting to Outlook.com must adhere to the following requirements:
    • (1) Sender is expected to comply with all technical standards for the transmission of Internet email, as published by The Internet Society’s Internet Engineering Task Force (IETF), including RFC 2821, RFC 2822 and others.
    • (2) After being given a numeric SMTP error response code between 500 and 599 (also known as a permanent non-delivery response), the sender must not attempt to retransmit that message to that recipient.
    • (3) After multiple non-delivery responses (see #2), the sender must cease further attempts to send emails to that recipient.
    • (4) Sender must not open more than 500 simultaneous connections to Outlook.com inbound email servers without making prior arrangements.
    • (5) Messages must not be transmitted through insecure email relay or proxy servers.
    • (6) The mechanism for unsubscribing, either from individual lists or all lists hosted by the sender, must be clearly documented and easy for recipients to find and use.
    • (7) Connections from dynamic IP space may not be accepted.
    • (8) Email servers must have valid reverse DNS records.
    • (9) Senders must not use namespace mining techniques against Outlook.com inbound email servers. This is the practice of verifying email addresses without sending (or attempting to send) emails to those addresses.

4. Authentication: Emails sent to Outlook.com users should include Sender ID authentication. While other forms of authentication are available, Microsoft currently only validates inbound emails via SPF and Sender ID authentication.

  • SPF [“Sender Policy Framework“: DNS record with the IP addresses of a domain’s mailservers used to test incoming connections]

So according to MS, if my test email sent to my free Outlook.com email is sent from any IP specified in the DNS record for the domain my mailserver is hosting (SPF) AND the signature of these test email can be validated by MS’s mailserver using the public key it retrieved from my DNS records (DKIM), then the email will pass their authentication tests and I should be allowed to connect, right? Let’s see…

2. Testing: Send Same Email to my Gmail & Outlook.com Accounts

My mailserver which will send the test emails lives on a business Internet connection with a static IPv4 & IPv6 Global Unicast Address which both resolve 360 degrees: name to IP and IP to name and neither of the IPs are on any Realtime Blackhole Lists (“RBLs”). The connection which puts the emails to receiving emails is made via TLS 1.3. And I *NEVER* email any direct sales solicitations; companies & recruiters tend to find me on LinkedIn because I’ve been a Linux & Network Engineer for over 20 years. The content of this email message is simply “Test email” which any competently engineered spam filters shouldn’t match.

I’ll send the same email, from the same email address, to both my Outlook.com & Gmail accounts. Then I’ll review in turn the SMTP logging of the connections between the servers and also the headers for each of the messages delivered successfully. As Gmail’s SMTP connection standards exceed Microsoft’s, if delivery of the test email to my GMAIL address SUCCEEDS then my mailserver ‘s compliance with Microsoft’s published security & anti-spam standards will be proven. If delivery of the same test email to my OUTLOOK.COM address FAILS after passing Google’s MORE stringent security measures, this proves that MS is applying arbitrary, unpublished standards based on business logic, unrelated to security to break the Internet into islands of email connectivity.

Test email #1: Sent to my GMAIL Account

We’ll do the Gmail test email first because there’s no tricks to their security standards: if you meet their published connection standards then your mailserver is allowed to connect and pass mail to accounts they host. Useful for comparative analysis with the MS email:

Gmail’s SMTP Connection: A reminder that the logging which follows is from MY side of the connection. It does not show testsanti-spam tests such as the presence of my IP on any RBLs, an SPF & PTR record for my mailserver’s IP. But it evidences that my test email passed a baseline assessment for correct security configuration for the email to be transferred across the TLS connection:

Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: initializing the server-side TLS engine
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: connect from unknown[192.168.4.129]
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: discarding EHLO keywords: CHUNKING
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: setting up TLS connection from unknown[192.168.4.129]
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: unknown[192.168.4.129]: TLS cipher list “kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES:!EXP:!MEDIUM:!LOW:!DES:!3DES:!SSLv2”
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:before SSL initialization
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:before SSL initialization
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:SSLv3/TLS read client hello
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:SSLv3/TLS write server hello
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:SSLv3/TLS write change cipher spec
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:TLSv1.3 write encrypted extensions
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:SSLv3/TLS write certificate
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:TLSv1.3 write server certificate verify
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:SSLv3/TLS write finished
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:TLSv1.3 early data
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:TLSv1.3 early data
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:SSLv3/TLS read finished
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: unknown[192.168.4.129]: Issuing session ticket, key expiration: 1679266251
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: unknown[192.168.4.129]: save session F7AF824F845CE2162918BBDFAE8866143BFA89308D50AE7A7ED4248FF4D78F71&s=submission&l=269488415 to smtpd cache
Mar 19 22:20:52 mail postfix/tlsmgr[356]: put smtpd session id=F7AF824F845CE2162918BBDFAE8866143BFA89308D50AE7A7ED4248FF4D78F71&s=submission&l=269488415 [data 136 bytes]
Mar 19 22:20:52 mail postfix/tlsmgr[356]: write smtpd TLS cache entry F7AF824F845CE2162918BBDFAE8866143BFA89308D50AE7A7ED4248FF4D78F71&s=submission&l=269488415: time=1679264452 [data 136 bytes]
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: SSL_accept:SSLv3/TLS write session ticket
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: Anonymous TLS connection established from unknown[192.168.4.129]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Mar 19 22:20:52 mail postfix/submission/smtpd[2910]: discarding EHLO keywords: CHUNKING
Mar 19 22:20:53 mail postfix/submission/smtpd[2910]: 097447CC6D: client=unknown[192.168.4.129], sasl_method=LOGIN, sasl_username=abc123@1networking.net
Mar 19 22:20:53 mail postfix/cleanup[2916]: 097447CC6D: message-id=<ed9b4d38-8a9b-2696-6f96-519fac008bfa@1networking.net>
Mar 19 22:20:53 mail postfix/qmgr[111]: 097447CC6D: from=<abc123@1networking.net>, size=906, nrcpt=1 (queue active)
Mar 19 22:20:53 mail postfix/submission/smtpd[2910]: disconnect from unknown[192.168.4.129] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8
Mar 19 22:20:53 mail postfix/smtp[2917]: initializing the client-side TLS engine
Mar 19 22:21:23 mail postfix/smtp[2917]: connect to gmail-smtp-in.l.google.com[64.233.184.27]:25: Operation timed out
Mar 19 22:21:25 mail postfix/smtp[2917]: setting up TLS connection to gmail-smtp-in.l.google.com[2a00:1450:400c:c0b::1b]:25
Mar 19 22:21:25 mail postfix/smtp[2917]: gmail-smtp-in.l.google.com[2a00:1450:400c:c0b::1b]:25: TLS cipher list “kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES:!EXP:!MEDIUM:!LOW:!DES:!3DES:!SSLv2”
Mar 19 22:21:25 mail postfix/smtp[2917]: SSL_connect:before SSL initialization
Mar 19 22:21:25 mail postfix/smtp[2917]: SSL_connect:SSLv3/TLS write client hello
Mar 19 22:21:25 mail postfix/smtp[2917]: SSL_connect:SSLv3/TLS write client hello
Mar 19 22:21:25 mail postfix/smtp[2917]: SSL_connect:SSLv3/TLS read server hello
Mar 19 22:21:25 mail postfix/smtp[2917]: SSL_connect:TLSv1.3 read encrypted extensions
Mar 19 22:21:25 mail postfix/smtp[2917]: gmail-smtp-in.l.google.com[2a00:1450:400c:c0b::1b]:25: depth=2 verify=1 subject=/C=US/O=Google Trust Services LLC/CN=GTS Root R1
Mar 19 22:21:25 mail postfix/smtp[2917]: gmail-smtp-in.l.google.com[2a00:1450:400c:c0b::1b]:25: depth=1 verify=1 subject=/C=US/O=Google Trust Services LLC/CN=GTS CA 1C3
Mar 19 22:21:25 mail postfix/smtp[2917]: gmail-smtp-in.l.google.com[2a00:1450:400c:c0b::1b]:25: depth=0 verify=1 subject=/CN=mx.google.com
Mar 19 22:21:25 mail postfix/smtp[2917]: SSL_connect:SSLv3/TLS read server certificate
Mar 19 22:21:25 mail postfix/smtp[2917]: SSL_connect:TLSv1.3 read server certificate verify
Mar 19 22:21:25 mail postfix/smtp[2917]: SSL_connect:SSLv3/TLS read finished
Mar 19 22:21:25 mail postfix/smtp[2917]: SSL_connect:SSLv3/TLS write change cipher spec
Mar 19 22:21:25 mail postfix/smtp[2917]: SSL_connect:SSLv3/TLS write finished
Mar 19 22:21:25 mail postfix/smtp[2917]: gmail-smtp-in.l.google.com[2a00:1450:400c:c0b::1b]:25: subject_CN=mx.google.com, issuer_CN=GTS CA 1C3, fingerprint=1F:86:84:A6:2E:21:1D:21:FD:2D:55:C1:8C:BC:3B:10:B8:13:ED:B2:1D:B3:A6:1C:FC:FF:ED:61:3E:88:20:E8, pkey_fingerprint=16:3B:AD:A5:DF:10:A9:01:4C:BA:0C:BA:33:41:1C:AE:E7:71:F0:D5:8F:F3:3C:0D:64:29:21:67:7A:0F:44:0C
Mar 19 22:21:25 mail postfix/smtp[2917]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c0b::1b]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
Mar 19 22:21:26 mail postfix/smtp[2917]: SSL_connect:SSL negotiation finished successfully
Mar 19 22:21:26 mail postfix/smtp[2917]: SSL_connect:SSL negotiation finished successfully
Mar 19 22:21:26 mail postfix/smtp[2917]: SSL_connect:SSLv3/TLS read server session ticket
Mar 19 22:21:26 mail postfix/smtp[2917]: SSL_connect:SSL negotiation finished successfully
Mar 19 22:21:26 mail postfix/smtp[2917]: SSL_connect:SSL negotiation finished successfully
Mar 19 22:21:26 mail postfix/smtp[2917]: SSL_connect:SSLv3/TLS read server session ticket
Mar 19 22:21:28 mail postfix/smtp[2917]: 097447CC6D: to=<abc123@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c0b::1b]:25, delay=35, delays=0.13/0.07/34/1.6, dsn=2.0.0, status=sent (250 2.0.0 OK  1679264487 g6-20020a056000118600b002c6e8af1038si6796680wrx.475 – gsmtp)
Mar 19 22:21:28 mail postfix/qmgr[111]: 097447CC6D: removed

Gmail’s Email Headers:

Although we can only see the SMTP logging of the connection from my side, we do have Google’s headers for the successfully transferred email which we can review:

From “View Source” in Gmail
Also from “View Source” Gmail

Test email #2: Sent to my OUTLOOK.COM Account

Let’s see what happens when we send the same email from my mailserver to my Outlook.com account:

Mar 19 23:19:26 mail postfix/submission/smtpd[3203]: initializing the server-side TLS engine
Mar 19 23:19:26 mail postfix/submission/smtpd[3203]: connect from unknown[192.168.4.129]Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: discarding EHLO keywords: CHUNKING
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: setting up TLS connection from unknown[192.168.4.129]
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: unknown[192.168.4.129]: TLS cipher list “kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES:!EXP:!MEDIUM:!LOW:!DES:!3DES:!SSLv2”
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: SSL_accept:before SSL initialization
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: SSL_accept:before SSL initialization
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: unknown[192.168.4.129]: Decrypting session ticket, key expiration: 1679266251
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: SSL_accept:SSLv3/TLS read client hello~
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: SSL_accept:SSLv3/TLS write server hello
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: SSL_accept:SSLv3/TLS write change cipher spec
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: SSL_accept:TLSv1.3 write encrypted extensions
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: SSL_accept:SSLv3/TLS write finished
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: SSL_accept:TLSv1.3 early data
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: SSL_accept:TLSv1.3 early data
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: SSL_accept:SSLv3/TLS read finished
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: unknown[192.168.4.129]: Reusing old session (RFC 5077 session ticket)
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: Anonymous TLS connection established from unknown[192.168.4.129]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: discarding EHLO keywords: CHUNKING
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: 2084E7CCF8: client=unknown[192.168.4.129], sasl_method=LOGIN, sasl_username=abc123@1networking.net
Mar 19 23:19:27 mail postfix/cleanup[3209]: 2084E7CCF8: message-id=<9b9fc50c-5ac2-d2ea-29d8-d1fd34712336@1networking.net>
Mar 19 23:19:27 mail postfix/qmgr[111]: 2084E7CCF8: from=<abc123@1networking.net>, size=889, nrcpt=1 (queue active)
Mar 19 23:19:27 mail postfix/smtp[3210]: initializing the client-side TLS engine
Mar 19 23:19:27 mail postfix/submission/smtpd[3203]: disconnect from unknown[192.168.4.129] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8
Mar 19 23:19:35 mail postfix/postscreen[3213]: CONNECT from [147.78.103.42]:26045 to [192.168.23.2]:25
Mar 19 23:19:35 mail postfix/postscreen[3213]: PREGREET 11 after 0.02 from [147.78.103.42]:26045: EHLO User\r\n
Mar 19 23:19:35 mail postfix/postscreen[3213]: DISCONNECT [147.78.103.42]:26045
Mar 19 23:19:57 mail postfix/smtp[3210]: connect to outlook-com.olc.protection.outlook.com[104.47.12.33]:25: Operation timed out
Mar 19 23:20:27 mail postfix/smtp[3210]: connect to outlook-com.olc.protection.outlook.com[104.47.14.33]:25: Operation timed out
Mar 19 23:20:27 mail postfix/smtp[3210]: 2084E7CCF8: to=<abc123n@outlook.com>, relay=none, delay=60, delays=0.15/0.06/60/0, dsn=4.4.1, status=deferred (connect to outlook-com.olc.protection.outlook.com[104.47.14.33]:25: Operation timed out)

And the “operation” will time out” forever. There are no headers to review as Microsoft is blocking the connection and the email will NEVER be delivered to my Outlook.com email account.

Conclusion:

The results are clear: if my mailserver had any material security misconfigurations or a bad reputation for spamming, Gmail would have blocked my connection- and I evidenced that they DIDN’T. Anybody that uses Gmail knows they’re pretty skilful at keeping their users’ inboxes free of spam. Testing reveals that my mailserver more than meets Microsoft’s published connection standards but is still being refused connections to pass email to their users. So purported “security” & “spam” concerns are evidenced to be a pretense to mask their anti-competitive behaviour which is breaking the Internet into islands of email connectivity. So for all Microsoft’s DEI blah, blah, they’re colonizing the Internet to maintain their stranglehold on email services. I tried to contact Microsoft directly to resolve the connectivity issue, but they make it impossible for their victims to speak to them. Anyhoo, if you’re not able to transfer email to Microsoft, don’t let these anti-democratic Seattle monopolists gaslight you: even if you meet their connection standards, your mailserver won’t be allowed to connect. Unless of course you’re a Google with a war chest to assert your connectivity rights for a free, fair and open Internet…

Leave a Reply