Score:-1

How to send an email with openssl and Microsoft Exchange Online?

vn flag

With Microsoft disabling basic auth in Exchange Online, I set out to add support Modern Authentication in our application. Our app sends basic email alerts. Currently we use SMTP basic auth or open relay for this, but Modern Auth would be a nice addition.

To fully understand the process, I'd like to go through the entire email process manually. I have a development tenant at Microsoft, in which I have registered our application. I have no issues in acquiring the Oauth token with an email scope. It's the communication with the SMTP server that I can't get through.

As the communication has to be encrypted, I use openssl (instead of telnet). I connect to the server with this command:

openssl s_client -connect smtp.office365.com:587 -crlf -starttls smtp

There is some feedback around SSL negotiation and then the server responds with:

250 SMTPUTF8

At that point I believe I am supposed to use the EHLO command. However, after

EHLO

The response is just (Server changes on every attempt)

' [AM4PR0101CA0056.eurprd01.prod.exchangelabs.com] 

At this point I'm not sure what to do. I believe it may be necessary to insert some domain after the ehlo command (to identify the Microsoft online tenant to connect to?). However, whatever domain I insert, the response is always:

501 5.5.4 Invalid domain name [AM4PR0101CA0056.eurprd01.prod.exchangelabs.com]

Can somebody explain how to initiate communications with a Microsoft Exchange Online tenant via OpenSSL? What do I put after EHLO? Am I connecting to the right address at all? I'm just trying to get to a point where I can issue a AUTH XOAUTH2 command to log in on my tenant.

I've been able to do the complete process om Gmail's smtp server (smtp.gmail.com). On there, it does not matter what you add after the ehlo command, after issuing it you will be greeted and can proceed to login with various AUTH commands.

Score:0
us flag
Rob

The EHLO is an "advanced" successor of the older helo and is intended to have your SMTP client introduce itself. So similar to saying "Hello! I'm Rob, nice to meet you." you need to provide your own hostname after the EHLO.

RFC 5312

Syntax:

"EHLO" "(space)" "( Domain / address-literal )" "CRLF"

The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4.

Some SMTP server implementations are more strict than others in requiring that the SMTP protocol is implemented correctly by clients connecting. Note that a bad SMTP implementation will usually (dramatically) increase your spam score.

vn flag
Ok, so I used a service like http://www.whatismyhostname.com/ to determine my hostname. smtp.office365.com doesn't accept this. The RFC says in 4.1.3 that alternatively, an address literal (IP address) in square brackets can be used. Doesn't work either. Does this work for you at all? If you have OpenSSL, this is a very easy test.
Score:0
vn flag

My problem was in the initial command:

openssl s_client -connect smtp.office365.com:587 -crlf -starttls smtp

And specifically the -crlf flag - without it I could enter anything after EHLO and still be greeted by the SMTP server and proceed to AUTH.

The flag seems to do something with line endings which this SMTP server is particularly picky about. So this command works for me:

openssl s_client -connect smtp.office365.com:587 -starttls smtp

I've read other sources that mention adding this flag to resolve issues, for me removing it did the trick. I recommend anyone with the same problem to try both.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.