Forum Discussion
Jan 12, 2017
Exchange Online - Mail User - without license and how to send email / SMTP access
Hi, tenant has E3 subscription and uses Exchange Online. We want to create external "mail contact" who can send emails through SMTP. So we created Exchange Online > Mail user. User can normally lo...
Guido Leenders
Feb 11, 2018Copper Contributor
Same problem here. We have a long list of service users in our on-premise environment, one per "service" such as Synology 1, Synology 2, Temperature sensor, Oracle RDBMS 1, etc. Their credentials are used to send email with authentication. For internal mail on Office 365 that should not be a problem. But when you want to relay outside, I will need to configure some other form of authentication like IP-address.
I agree with Hrvoje Kusulja that this is a functional change between on-premise Exchange and cloud.
Feb 11, 2018
The best way is to yuse method 3 on the following article. https://support.office.com/en-us/article/How-to-set-up-a-multifunction-device-or-application-to-send-email-using-Office-365-69f58e99-c550-4274-ad18-c805d654b4c4?ui=en-US&rs=en-US&ad=US&fromAR=1
For this kind of scenarios is what is best to implement and it's configured in several customers.
- Guido LeendersFeb 11, 2018Copper Contributor
Yes, that one works best. We use it with cname on smtp.COMPANY.TLD. The connectors are somewhat restricted compared to Exchange on-premise.
- Feb 11, 2018
cname is not ok, because of server certificates / ssl / tls..., so better use original server name.
Also, if you have dynamic public ip address, then this method is not possible.
It is better that Exchange team implement new functionality, something like Exchange Online - Application user, which will have username/password for SMTP submission, and will not require a license.
- Guido LeendersFeb 11, 2018Copper Contributor
Yes, you are right again, cname has indeed drawback that the certificate does not match the name. I've chosen nonetheless for cname to make it easier to switch. TLS is not so strict currently in our nodes. But it is indeed not the right approach for optimal security.