<![CDATA[Incisive Medical Systems]]> <![CDATA[Sending emails using Microsoft365 (Office365)]]> Emails can be sent through Office365 email servers using either:

  • Authenticated Client SMTP, or
  • SMTP Relay (using an Outlook connector)

Authenticated Client SMTP is the preferred option. SMTP Relay may be deprecated by Microsoft

Authenticated SMTP

Authenticated SMTP requires authentication to be enabled at the Microsoft 365 Tenant and the Mailbox level.  It is now enabled by default.

The per-mailbox setting to enable (or disable) SMTP AUTH is available in the Microsoft 365 admin centre or Exchange Online PowerShell.

  1. Open the Microsoft 365 admin center and go to Users > Active users.
  2. Select the user, and in the flyout that appears, click Mail.
  3. In the Email apps section, click Manage email apps.
  4. Verify the Authenticated SMTP setting: unchecked = disabled, checked = enabled.
  5. When you’re finished, click Save changes.

In SPM/PHM configure the options in Setup > Provider > Email   (for each Provider)

SMTP Server Settings

SMTP Server Name:    smtp.office365.com (or outlook.office365.com)
SMTP Encryption:       TLS
SMTP Server Port:      587  (needs to be an open Outgoing port)

Account Authentication

SMTP Authentication required
Authentication Method:     AUTO or LOGIN
Account Username:          The email address of a user account
Account Password:           The password for the user account

Note:

Enable SMTP AUTH for specific mailboxes

The per-mailbox setting to enable (or disable) SMTP AUTH is available in the Microsoft 365 admin center or Exchange Online PowerShell.

  1. Open the Microsoft 365 admin centerand go to Users > Active users.
  2. Select the user, and in the flyout that appears, click Mail.
  3. In the Email appssection, click Manage email apps.
  4. Verify the Authenticated SMTPsetting: unchecked = disabled, checked = enabled.
  5. When you’re finished, click Save changes.

 

SMTP Relay

In SPM/PHM (release 409.6 or newer) configure the options in Setup > Provider > Email   (for each Provider)

SMTP Server Settings

SMTP Server Name:    <your-domain>.mail.protection.outlook.com
SMTP Encryption:       TLS
SMTP Server Port:      25  (needs to be an open Outgoing port)

Account Authentication

SMTP Authentication NOT required

Troubleshooting

  • Use the Check Connection and Send Test Email.
    Look at the log as it will explain the problem.  Scroll to the bottom of the log for the most recent entry.
  • Check port 25 or 587 are open  (Use Telnet if you are not sure)
  • Check .NET Framework 4.8 or newer is installed.
  • Get your Office365 administrator to go to the Azure Active Directory and check the Sign-In logs to view the connection attempts.

]]> <![CDATA[SMTP2GO DNS configuration for DKIM & SPF records]]> If you are using the SMTP2GO service to send out-going emails, to improve the deliverability of emails so they don't land in the Junk-mail inbox, you will need to add CNAME records to your domain host service provider.

Your domain needs to be added to the 'Verified Senders' function in SMTP2GO > Settings, then make the changes to your DNS host.

For example

In addition to the above records, we have found that you should also have a SPF record added as a CNAME to the domain registry, with a minimum of: v=spf1 include:spf.smtp2go.com mx ~all

In order to improve your delivery rates, we always recommend creating an SPF record and a DKIM record in your DNS settings. By doing so, this tells the recipient server that you have given our servers permission to send on your behalf. Without these small changes, recipient servers may flag your emails as spam and either dump them in the junk folder, or else just not accept them at all.

SPF (Sender Policy Framework) records tell the recipient server that you have given SMTP2GO’s servers permission to send on behalf of your domain name. A DKIM (Domain Keys Identified Mail) signature digitally signs your emails so that your particular domain name can claim responsibility for the email sent. If you haven’t set up a DKIM record, SMTP2GO signs your emails with our domain name. Gmail recipients will see that emails are sent “via smtpcorp.com” or “via smtp2go.com” and you may experience some issues when sending to some recipient servers such as Hotmail/ Yahoo/ Gmail and AOL. If you need to set up a DMARC record (which is useful to prevent spammers sending phishing emails from your domain name) then you will absolutely need to create a DKIM signature.

SPF Record Testing Tool: https://www.kitterman.com/spf/validate.html? 

Note:
Some older email servers are not able to properly process emails.  SMTP2Go can be configured to 'Maintain the Return-Path'.  See: https://support.smtp2go.com/hc/en-gb/articles/16994667206937-Maintaining-the-Return-path 

]]> <![CDATA[Verifying your SMTP2GO account login]]> Most SMTP (Outgoing) email servers now require you to have specific features enabled with your smtp account login, so that the receiving email server can trust the content in the email and that it is not likely to be spam.  If it is not configured correctly you may be getting the following error when you send an email:

The best option is to ensure that your domain name has the correct DMARC, DKIM & SPF settings (talk to your IT provider to check these are enabled).

If you are using the SMTP2GO outgoing email service, you should also use the DMARC/DKIM/SPF settings, but you can also just verify the FROM: email address that you are using to send your emails with.  Note that the domain verification is preferential as the single email verification will include the words "via smtpcorp.com" in the header area of the email.

To check whether the SMTP2GO account is verified:

  1. Login to your SMTP2GO account
  2. Go to Sending > Verified Senders
  3. The first view is of your 'Sender Domain' status.  If the domain is verified it will appear with a green background, otherwise it will be orange


    Use the 'Add Sender Domain' button for the details that your IT provider will need to add.

  4. You can also click on the 'Single sender emails' link

  5. Use the 'Add single sender email' button and enter the email address that you are sender your emails from.  Then check that you have received the email and click on the Verified option in the email.


    It will then appear in the SMTP2GO screen as being verified
]]> <![CDATA[Prevent email going into spam or junk folders.]]> Most of the major email servers will look at the domain name part of your email address to check that the correct security settings are included in the email header to allow the email server to authenticate that it is from a genuine email address and not created as part of a spam storm.  The first two steps below are the most important.

  • Try to use the same domain name for your 'From' address, 'Reply-To' address and also the 'SMTP Server Name' (Setup > Provider > Email).  Some email servers will compare the domain names used in the out-going email and if they differ they rank the email for spam accordingly.
  • Add the relevant DMARC, SPF and DKIM settings to your domain host (talk to your IT provider) - this is very important.
    Use https://mxtoolbox.com to check the DMARC configuration of your domain name e.g. incisive.co.nz
  • You can also use https://easydmarc.com to check that your SPF record is valid.  An invalid or absent SPF record will definitely cause your email to be regarded as spam, by some older type of recipient email servers (e.g. xtra.co.nz)

Additional options to check the deliverability of your email.

  • If you have a @gmail.com address, create a free account at Google Postmaster Tools. This will give you the ability to see various metrics that Google/Gmail keeps for your domain name and will let you see if there is a problem. Note: it will take a few days for any stats to appear after you create an account with them.
  • Check that your domain name isn't on a domain blacklist.  You can search for your domain name at MXToolbox. Also search for your domain name at URLVoid.
  • Search for your domain name at BorderWare Watchguard. This will show BorderWare's assessment of the reputation of all IP addresses that are sending emails from your domain name. Any servers that have a bad reputation may have become compromised, or may be sending out emails that have generated spam complaints in the past, and should be investigated. You can do a similar search for your domain name at SenderScore.org.
  • If you're sending from a free email service such as Hotmail, Yahoo, etc. your emails are often treated more suspiciously by recipient spam filters. It is always better - and more professional - to send emails from your own (or your business') domain name. You should never send emails from a Yahoo or AOL email address (as of April 2014) as these domains are now restricted by their DMARC policies. You should also not send from a Gmail email address as of June 2016 due to Gmail's new DMARC policy.
  • If you place links in an HTML email, it is best to not display the actual link (http://www.etc...) in your email. Many email programs now have anti-phishing technology which treats such links suspiciously. If the underlying URL of your link is different from the URL displayed, then your email will be marked as spam by email clients such as Thunderbird. And never use an IP address in a link.
  • Never use URL shorteners in an email.

You can test the likelihood of your email being regarded as Spam by using email checking sites such as https://www.mail-tester.com/   You will be provided with a unique email address like test-ilg76rjn5@srv1.mail-tester.com  that you can put as the patient's email address and then try sending emails from different locations in the Incisive application.  You will be provided with a score.  Anything with a score of -5 or less is likely to be marked as Spam.  Scores of -1 or -2 should see the emails successfully delivered to the recipient's Inbox.

]]> <![CDATA[Setting up Gmail as an SMTP account for a Provider]]> Setting up Gmail as an SMTP account for a Provider

 

To setup Email for a Provider using a Gmail account, go into:

Setup > Provider  > Email    (as below).

When you try to Test Connection it will fail and the Gmail account will receive a Security alert.

 

You will need to get the client to login to the Gmail account to do the next steps.

  1. There will be a security alert email in the inbox.

2.   Click on “Yes it was me” and you will go to the Less secure app blocked Click on “Learn more”

3.    From the Less secure apps page, click on “Less secure app access” link.

4.   Change the setting to ON.

5.    If you retry Test Connection, it should now allow emails through.

  • With upcoming security changes by Google, new application connections will not be able to be made after July 2020.
  • Existing connections will stop after Feb 2021.

]]> <![CDATA[Microsoft365 Managed Authentication for importing emails]]> Microsoft now requires third-party applications, that want to import emails from a Microsoft 365 (Office 365) IMAP service, to use an access token for authenticated connection requests. Basic Authentication, which uses a Username and Password, is no longer supported by Microsoft.  The Incisive application will automatically recognise whether the Microsoft account is configured to only allow ‘Managed Authentication’ connections.

You need to register the Incisive application in your Azure Active Directory tenancy, that hosts your Exchange Online and grant it permissions. The AppID and Secret Value, of the app you register, are required for SPM/PHM to access the Microsoft 365 account.

The steps required are:

  • Register the ‘Message Centre’ as an App

  • Assign Users & Groups to the App

  • Assign Permissions to the App

  • Create a Secret

  • Enter the App ID and Secret into the Incisive program

Detailed instructions to configure the Azure portal are available from:

https://incisivesupport.com/docs/Microsoft365_OAuth2_Config.pdf

]]> <![CDATA[Email Alias accounts]]> You can add 'alias' email accounts to Gmail and Office mailboxes, without them costing anything.  The incoming emails, addressed to the alias accounts, will all appear in the main mailbox account.

The MFA function for Incisive inCLOUD requires a unique email address for each inCLOUD account and if you don't have individual practice emails or you don't want to use a personal email, you can easily create additional alias accounts.

Google Gmail

Send emails from a different address or alias - Gmail Help (google.com)

How to set up Gmail or Google Workspace (G Suite) aliases – cloudHQ Support

Microsoft Office

Add another email alias for a user - Microsoft 365 admin | Microsoft Docs

]]> <![CDATA[Sending emails using Apple's SMTP service for icloud.com or me.co...]]> See Sending emails using Apple's SMTP service for icloud.com or me.com email accounts.

If you are using Apple's icloud.com or me.com SMTP service to send emails from Incisive applications, you will need to create an 'App-Specific' password to use for the Authentication password.

In Apple's words "App-specific passwords are passwords for your Apple ID that let you sign in to your account and securely access the information you store in iCloud from a third-party app. For example, use app-specific passwords with mail, contacts, and calendar services not provided by Apple."

https://support.apple.com/en-us/HT204397

If you follow the links in the above page and log into your apple account you can find the option to Generate Password...  for App-Specific Passwords.

5Y9znGE2uBwAAAAASUVORK5CYII=

You can have up to 25 App-Specific passwords.

The SMTP settings you need to use are available for your icloud.com or me.com email address from the following URL

https://support.apple.com/mail-settings-lookup

]]> <![CDATA[Using Google App-Password option]]> Microsoft and Google are changing the connection requirements for third-party applications (like Incisive) to send emails through their SMTP (out-going) email services.  These connections now require a token to be requested and passed back to Incisive application, instead of just requiring your encrypted login & password, for the Microsoft & Google services to allow the email to go through.

Previously, Gmail had an option to allow 'less secure' applications to send emails through their SMTP service, however this option has now been disabled.  There is a different security option called 'App Password' which may work for you, but is only available if you have 2FA authentication enabled on your Google account.

Google Support provides the following knowledgebase article https://support.google.com/accounts/answer/185833?hl=en

Enter your gmail address and the newly generated password into Setup > Provider > Email

]]> <![CDATA[OAuth requirement for Google & Microsoft SMTP out-going email ser...]]> Microsoft and Google are changing the connection requirements for third-party applications (like Incisive) to send emails through their SMTP (out-going) email services.  These connections now require a token to be requested and passed back to Incisive application, instead of just requiring your encrypted login & password, for the Microsoft & Google services to allow the email to go through.  It is possible that these security requirements are being enforced in consideration of the current world-wide tensions.

The symptom may appear as an error message with text of 'Bad Credentials' or 'Username and Password not accepted' and your emails can no longer be delivered.

It is possible that you will notice that emailing functions, outside of the Incisive applications, such as 'Scan to Email' from your multi-function device (scanner/printer), are also likely to run into the same problem sending emails.

Previously, Gmail had an option to allow 'less secure' applications to send emails through their SMTP service, however this option has now been disabled.  There is a different security option called 'App Password' which may work for you, but is only available if you have 2FA authentication enabled on your Google account.

We have provided Knowledgebase articles with references to the relevant Google, Microsoft & Apple app-password support information and how to add it to the Incisive application.

As an alternative SMTP email delivery service, you could look to use a third-party SMTP service such as SMTP2Go.com, which we have used for many years and are quite happy with.  Their pricing is very reasonable, with it being free for up to 1000 emails per month or US$10 per month for up to 10,000 emails per month.  If you're not sure how many you send, start with the free plan and they will notify you if you need to move to the next level. 

There are many other SMTP providers such as SendGrid (who we have also used) or others like ClickSend or Mailgun. Your IT technician may also recommend others.

It is possible these SMTP providers will require you to use a private domain address (not @gmail @yahoo @outlook @me etc.).  You can acquire your own domain address and use it just for emails.  A domain name may cost about $30 per year and email services can often be available for about $5-10 per month.  Domain address and hosting services are available from many providers like crazydomains.co.nz   It will be important to ask your IT technicians to configure your domain to use the SPF, Dmarc & DKIM settings, to ensure better reliability of getting your emails to the patient's Inbox.  The Incisive Helpdesk does not provide these services.

If you do use SMTP2Go, or a similar service, your emails will still be delivered using your usual email From: and ReplyTo: email addresses, which you have entered in the Incisive application.

]]> <![CDATA[Gmail SMTP relay service errors]]> Advanced email routing through the Google Gmail servers

https://support.google.com/a/answer/6140680#invalidcreds6-20020a17090302c600b0015eca1bc518sm78521plk.143%20-%20gsmtp

SMTP relay: Route outgoing non-Gmail messages through Google

If your organization uses Microsoft Exchange or another non-Gmail SMTP service, you can configure the SMTP relay service to route outgoing mail through Google. You can use the SMTP relay service setting to filter messages for spam and viruses before they reach external contacts. You can also apply Google Workspace email security and advanced Gmail settings to outgoing messages

https://support.google.com/a/answer/2956491 

]]> <![CDATA[Problem trying to email: Socket Error: WSAEWOULDBLOCK]]>

Socket Error: WSAEWOULDBLOCK

Posted on

NOTE: If this error occurred while trying to establish an FTP data connection, also see this: http://cknotes.com/?p=282

A WSAEWOULDBLOCK error when trying to establish a TCP/IP socket connection indicates one of the following conditions:

  1. A firewall at either the client or server side is blocking the connection.
  2. There is no server listening at the remote host:port to accept the connection
  3. Some other software, such as an anti-virus or anti-spyware program is blocking the connection.
  4. The server was too slow in accepting the connection.  Increase the value of the ConnectTimeout property.

You may open a DOS prompt and try to telnet to the remote host:port to test connectivity. This page provides more information: WSAEWOULDBLOCK

Note: It is impossible for the client to distinguish between any of the cases described above.  It’s similar to if you were knocking on a door and nobody answers — you have no information — you don’t know if the person simply chose not to answer the door, if the person is not home, or if the person simply cannot hear the knocking.  In all cases, the client’s knowledge is the same: there is no response and you have to decide how long you’re willing to wait…

]]> <![CDATA[550 5.7.64 TenantAttribution; Relay Access Denied]]> Sending emails through Office365 sometimes causes message send failure with an error of 550 5.7.64 TenantAttribution; Relay Access Denied.

  1. In Office Admin go to Exchange
  2. In 'Mail Flow' go to  Connectors
  3. Use the wizard to complete the Connector process.

Make sure the external IP is recorded as an allowed address on the Inbound Connector in Office 365:

InboundConnector2

 

 

 

 

 

 

 

 

 

Also, add the IP address to the SPF record in Public DNS like this:

v=spf1 ip4:, include:spf.protection.outlook.com ~all

One other possible cause of this issue is if the application, when it composes the email, uses a domain other than what is on the accepted domains list. For example, if your tenant has 3 defined domains – BobsGarage.Com, TimsGarage.Com andJohnsGarage.Com and the application sending the email uses a domain like GaragePower.Com, then the connector in Office 365 will reject the email. If you receive the relay error, here is the order I would take for troubleshooting:

  • Verify Sender address is using an accepted Domain (in the application, or message header)
  • Send the email to an internal recipient – check headers for IPs to match in the connector
  • Check your SPF record to make sure all IP addresses are listed as well

 

]]> <![CDATA[Emails not being sent - testing the SMTP server]]> If emails are not being received by the intended recipient there are a number of items to consider.  Usually, if there is a problem with sending the email out of your mail server, you would receive quite a detailed error message which will include, somewhere in the text, the reason that the emails are not going out of your server.

Check the following:

1. Are the settings for your outgoing mail server correct.
    Use http://mxtoolbox.com/diagnostic.asp to check that your SMTP (outgoing) mail server details are correct.

 

]]> <![CDATA[Email issues - 'aborting handshake because of fatal alert']]> A Google search of 'aborting handshake because of fatal alert' comes up with the following:

"The signer of the certificate can not be validated on your system. Either the server has a self signed certificate or your system doesn't have the latest server authorities available to it."

The problem seems to be caused by the latest version of the AVG anti-virus software, with scanning of outbound SMTP email somehow causing this fault.

If SMTP scanning is disabled, then email can be sent from the Incisive application without incident.

]]> <![CDATA[Updating the Client Secret when importing emails from Office365]]> If you are importing emails into the Message Centre from a Microsoft365/Office365 mailbox, Microsoft require you to authenticate the connection through their Azure portal.

The 'Client Secret' value expires and needs to be updated. When it has expired you will see a Microsoft error message and the following information will appear at the bottom of it:

Information on the creation and updating of the App ID and Client Secret values in the Azure portal are available from: https://incisivesupport.com/docs/Microsoft365_OAuth2_Config.pdf 

In the Incisive application you need to update the Client Secret value in the 'Secret' field in Setup > Provider > Config 3 > Edit, for each Provider.  The App ID does not need to be changed.

]]> <![CDATA[SMTP test email not working - ActiveX component not creating inst...]]> If the Test Email or Test Connection functions are not working or emails can't be sent and an error appears "ActiveX component not creating instance of object", it is possible that the Chilkat files are not correctly installed or registered.

Using RegisterBatch.exe may not help.

Use ChilkatSetup.exe (which is in the \spmwin directory) to install the necessary files and register them.

Make sure the virus checker and UAC are turned off first and you are using a login with Administrator rights

]]> <![CDATA[Testing the SMTP server connection]]> Go to this site and use the SMTP test option.  It has a very good set of diagnostic tools.

https://mxtoolbox.com/NetworkTools.aspx?abt_id=AB-402&abt_var=Control

It will report information regarding the connection and transaction time.

 
The MX  test is also good for diagnosing email problems.

]]> <![CDATA[Office 365 - Give mailbox permissions to another user ]]> Office 365 by default can only send emails from one email account (the account name).  Errors will occur if you try and send using the operator email address etc.

This may be able to be addressed by configuring Mailbox permissions.  Refer to the article below.  This should be carried out by the hardware technician or client.

https://docs.microsoft.com/en-us/office365/admin/add-users/give-mailbox-permissions-to-another-user?view=o365-worldwide#send-email-on-behalf-of-another-user

]]> <![CDATA[Emails rejected by receiving email server]]> Some emails are being rejected by receiving email servers because the email is not using the TLS encryption protocol.  @gmail.com email addresses are often affected as the Gmail servers aggressively reject non-encrypted emails.

in Setup > Provider > Email  check that your email settings are set to send using the TLS encryption.  Contact Incisive for the security code to edit the settings

You can also use the https://checktls.com website to check your Sending settings and also whether the receiving email server will accept emails from you.

Test your Sending settings https://www.checktls.com/Testsend 

Test the receiving email server  https://www.checktls.com/TestReceiver 

]]>