We have a windows service that collects mail from via an imap connector and then processes that email and attachments into a database. Is there a way that we can do this using OAuth2 when exchange online removes support for basic authentication? There is no user interface to the service or user access to teh system when it is running beyond the start and stop of the service.
We are currently using Chilkat's excellent Imap component.
Yes, Microsoft have finally released support and documentation for this in Exchange Online. See the following Microsoft document:
Authenticate an IMAP, POP or SMTP connection using OAuth
Related
Does Somebody know how I can see on the Exchange server 2016 if my client is configured like POP3 or MAPI client?
Somewhere in the Logs?
Thanks in advance
If you are using Outlook with Exchange 2016 somewhat 'standard' installation then MAPI over HTTP/S will be automatically enabled and your Outlook clients will be using it to connect. Then you can use the IIS logs to view the connections (these will be MAPI only).
If you are using a POP3/IMAP clients and the services are enabled on Exchange then I think you need to enable protocol logging via Set-PopSettings and Set-ImapSettings respectively and then review the protocol logs to see the connections. Refer to this article for more info on these logs.
Microsoft will end support for basic authentication in Exchange Online remote powershell October 13th, 2020.
Server-to-server communication can be done using the System.Management.Automation.Runspaces.WSManConnectionInfo class with basic authentication. What is the supported way for an on-premise daemon application to run remote powershell in Exchange Online when basic authentication is no longer supported?
If you don't want to rewrite your remote PowerShell code to use the new V2 Exchange Online Management module shown by #stukey above, you can use an alternative workaround by using ADAL (or a similar library) to fetch an access token from AzureAD, then use the token as password when constructing your PSCredential.
If you add ?BasicAuthToOAuthConversion=true to the connection URI, the server will then pull the token from the basic auth header and use modern authentication with the token instead.
The workaround is outlined here and semi-documented by Microsoft here.
Assuming your daemon application is using a Service Account ID without MFA, then you can utilise the new V2 Exchange Online Management PowerShell module to connect to EXO using Modern Auth. It handles everything for you, so you can still initiate a connection using your Service Account username and password credentials, and the module will use those creds to get a token from Azure AD and then authenticate to EXO using Modern Auth. Works great if your Service Account creds are managed by a separate password vault solution. If you can’t use credentials-based auth, then Microsoft are working on an update to the EXO module that will allow you to authenticate to EXO using a registered Azure AD app together with certificate-based auth. That should be coming soon...
This page states that before an application can access the API (I'm particularly interested in the Calendar API), it must be registered with Azure AD. Is this also true for organizations that may host their own Exchange servers?
Could someone provide a breakdown of what's necessary for me to get started with accessing the API to access the users' Calendar? I'm aware of the API reference, but I'm not entirely sure what's necessary to do before I can use the API.
That page is for Office365, not self hosted ones.
You can access your local/self hosted Exchange server with Exchange Web Services by using username/password, or even your local AD if you set it up correctly.
The API it is talking about is not available to on-premise Exchange Server, it is only available to Exchange Online in Office 365. This may change in the future, but currently you cannot use it in on-premise. Exchange Web Services is the way to go for on-premise.
Is this possible to do using ASP.Net in C#?
We have exchange in the cloud and access using outlook 365.
If it is possible, how do you connect and can you access mail and mail attachment from a remote application?
Use the Exchange Web Services API: http://msdn.microsoft.com/en-us/library/office/dd877045(v=exchg.140).aspx
I am working on .net applicaton that need to send emails to clients. I am trying to figure out what would be that best solution to send emails. Here is what i have considered. Could you please suggest what would be the best way to go for?
1>Windows server 2008 in built smtp
service.
2>Exchange server hosted in our
datacenter.
3>Use google apps for sending
emails(Basically same as gmail like
for custom domain).
I have explored all options and below are findings.
1>I think would be way to go. Also
supports drop in directory to send
emails so can achieve disconnected
email activity.
2>Application would be tied up with
availability of exchange server and
we dont have any exchange server
support personal. Only developers
poke around in exchange server and
got it working. So if option 1 is as
good as 2 then would like to go with 1.
Is there any drop in directory feature in exchange server like 1?
3>Tried gmail smtp stuff didnt
work. I was receiving timeout error.
Also there is no guarantee that
gmail will send our mail
reliability. They can decide anytime
to stop sending our mails as we are
using free standard version of
google apps.
Other questions:
I installed smtp service in windows server 2008. Now to use this do i need to change any MX record and anything? What i need to do so it can send email using my domain name. Or it can send email for any domain?
I would use a hybrid of 1 and 2. Use local SMTP, but have it relay to your exchange server. Emails will queue if it can't relay to exchange and you have one server(s) that handle all of your outgoing/incoming mail. This support doc explains this setup: http://support.microsoft.com/kb/303734
You only need an MX record if you'll be receiving mail from that domain too.
I would also put in a reverse DNS entry for your domain, which will help with spam detection.