cancel
Showing results for 
Search instead for 
Did you mean: 
Data Engineering
cancel
Showing results for 
Search instead for 
Did you mean: 

Random SMTP authentication failures to Office 365 (Exchange)

kdkoa
New Contributor III

Hey all-

I have a python script running in databricks notebook which uses smtplib to connect and send email via our Exchange online server. At random times, it will start getting authentication failures and I can't figure out why. I've confirmed that the email and password are correct, and the user on the Office 365 side is set up correctly. I'm not seeing any account lockouts, or email thresholds being hit, just errors that say 'bad username or password.'

Has anyone else run into this?

1 ACCEPTED SOLUTION

Accepted Solutions

kdkoa
New Contributor III

Thanks Brian, this issue was actually solved. The dev I was working with found that he was replacing the password variable accidentally via a call to a different notebook. Silly devs always blame the systems, not the code 😐

View solution in original post

4 REPLIES 4

Hubert-Dudek
Esteemed Contributor III

If message is "'bad username or password.'" my guess is that it is on Exchange side.

kdkoa
New Contributor III

I would agree, but the majority of the time it works fine, using the same password, pulled from the same Key Vault in Azure. That's why I'm wondering if it's something with smtplib or how databricks handles outbound connections.

Anonymous
Not applicable

Hi kdkoa, this sounds like an intermittent issue. Assuming the code around your authentication and/or your secrets don't change a lot or not programmed to do so, you will likely need to check with o365 on this.

If this were some other connection related problem, you'd be more likely to run into timeouts or connection refused errors. Our platform environments are quite static so most likely the problem is on the server side. It's at least worth investigating there; perhaps there are other messages in the logs that could help.

kdkoa
New Contributor III

Thanks Brian, this issue was actually solved. The dev I was working with found that he was replacing the password variable accidentally via a call to a different notebook. Silly devs always blame the systems, not the code 😐

Welcome to Databricks Community: Lets learn, network and celebrate together

Join our fast-growing data practitioner and expert community of 80K+ members, ready to discover, help and collaborate together while making meaningful connections. 

Click here to register and join today! 

Engage in exciting technical discussions, join a group with your peers and meet our Featured Members.