Has anyone had success using Office 365 for SMTP with Looker?
I get this error when attempting to send a test email:
Failed to send mail: 504 5.7.4 Unrecognized authentication type
I’m selected the check box for SSL/TLS. I did note that the setting I’ve had to use with another tool is START TLS. I’m not clear on whether that variant should be handled by the SSL/TLS option.
Did you ever get this answered and working? I’m looking to do the same thing.
Nope. I haven’t tried since, but the options don’t look like they’ve changed much. We’ve been using the default email settings, which are less of an issue now that we’ve had our IT team add the address (and potentially some IPs, I don’t remember) to our global whitelist in 365.
Hey @jyau and @srivera1 ,
This is a known issue that our engineering team is working on. There are some workarounds you may be interested in; on this Microsoft article we have had success with options 2 and 3. For option 3, I recommend following these instructions (you’ll need to be an admin on your Office365 account):
- Once logged into Office 365, click the Admin app> 1. From the navbar on the left scroll down to ADMIN, then click Exchange.> 1. From the navbar on the left click Mail Flow> 1. Click the Connector tab (on the right)> 1. Click the plus button> 1. In the “From:” field select “Your organization’s email server”, in “To:” select “Office 365”. Click Next> 1. Enter a name and a description. These can be anything you like. Make sure “Turn it on” and “Retain internal Exchange email headers” are checked. Click Next.> 1. For “How should Office 365 identify email from your email server?” select the “By verifying that the IP address of the sending server matches one of these addresses that belong to your organization”.> 1. Click the plus button and enter the IP address or range that Looker will be sending email from. Click Next.> 1. Click Save.
For step 9, if you are hosted by Looker you can find the range of IP addresses that we use on this page.
Once you’ve gone through the instructions above to set things up in Office 365 the next step is to set up Looker’s SMTP page. You’ll want to use custom SMTP and the only thing to note is that you leave the username and password blank.
Hi,
has this been resolved yet? Our security team are not keen for this work around.
Hey @IanT ,
This is on our engineering team’s radar. If you’d like to provide further details of your use case or security team’s concerns feel free to visit help.looker.com with those details!
Hi, I know/understand very little about this however security told me this:
“whitelisting some outside servers we have no idea how well they are managed to peer into our email tenant is not a great security practice”.
We will probably end up using the default server settings until TLS is implemented.
Thanks
Hey @IanT ,
Thanks for providing those details! I’ve passed them along to the team.
Hi,
Has there been any movement on this?
Thanks!
Any update on the internal discussion around improving this? Thanks.
Hi @balduncle ,
The engineering team is still working on this. At the moment there isn’t a timeline for improvements but if you have any further context on your use case to provide please send that along to help.looker.com so we can add that to the discussion!
Just following this up, we will want to move to you guys hosting our instance but would really like our scheduled mails to come from ourselves so this (along with a handful of other considerations) is a blocker.
There hasn’t been any movement on this, but I’m looking for some more visibility. Your little looker-hosted carrot dangle might be enough to open some eyes ��
Just checking in on the status of this internal discussion. Our security team will only allow username/password authentication for SMTP, so this is currently blocking any use of email within the application.
The main concern is that with a connector setup our O365 environment would be exposed to IP spoofing, potentially allowing an attacker to send what would appear to be authenticated email from our domain.
Thanks for checking in— This has historically not been prioritized very highly, but we have just recently rolled out some new internal prioritization guidelines. I’m taking this one back to the triage step and will report back with some honest info what our next steps will be on it.
Thanks for the transparency @izzymiller
To add more context, while this is a security issue at it’s core, there are downstream effects that are just as significant that have nothing to do with security, but more with the efficacy of the product for us as a business.
This is critical for us because it means we have to disable email until we can use username/password auth for SMTP, meaning that scheduled runs and delivery of Looks via email isn’t possible and users have to download data first in order to share it.
Both of those contribute to a poor UX, and I fear will make it more difficult for our business users to buy-in to and be excited about using Looker.
Not being able to use the scheduling and delivery via email capabilities just adds manual busy work that could otherwise be automated.
Thanks for the detailed context, Cole.
cole.elliott:
scheduled runs and delivery of Looks via email isn’t possible and users have to download data first in order to share it.
This is definitely not the experience we want to create for your team. Passing this onwards, as I mentioned, and I’ll be looping back here with what I find out.
Sure thing @izzymiller , and thanks for following up on this for us.
Checking back in: We haven’t yet fully scoped this out in terms of priority, but are going to explore it as maybe fitting into some general improvements to our email infrastructure that we’ll be doing soon. I’ll keep you posted, and you can also feel free to reach out to support to check back in anytime as well.