Hey Rick,

We currently use Chilkat's active x control to send email via SMTP. We're running into 2 problems. 1 It (at least our version of it) doesn't support HTML, and 2, We have a lot of customers that use gmail with allow less secure apps off and it looks like that won't be supported much longer...

I found your wwSmtp and it looks like it supports SSL (does it support TLS as well?) and HTML which is great. Does it support oAuth to authenticate with gmail? Reason I ask is it looks like gmail has plans to end SMTP authentication all together. Here's the email we got from google:

Starting February 15, 2021, G Suite accounts will only allow access to apps using OAuth. Password-based access will no longer be supported.

Dear Administrator, We’re constantly working to improve the security of your organization’s Google accounts. As part of this effort, and in consideration of the current threat landscape, we’ll be turning off access to less secure apps (LSA) — non-Google apps that can access your Google account with only a username and password, without requiring any additional verification steps. Access through only a username and password makes your account more vulnerable to hijacking attempts. Moving forward, only apps that support a more modern and secure access method called OAuth will be able to access your G Suite account. Access to LSAs will be turned off in two stages:

1. June 15, 2020 - Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off.
2. February 15, 2021 - Access to LSAs will be turned off for all G Suite accounts. What do I need to do? To continue using a specific app with your G Suite accounts, users in your organization must switch to a more secure type of access called OAuth. This connection method allows apps to access accounts with a digital key instead of requiring a user to reveal their username and password. We recommend that you share the user instructions (included below) with individuals in your organization to help them make the necessary changes. Alternatively, if your organization is using custom tools, you can ask the developer of the tool to update it to use OAuth. Developer instructions are also included below. MDM configuration If your organization uses a mobile device management (MDM) provider to configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles, these services will be phased out according to the timeline below:
3. June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for new users.
4. February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for existing users. Admins will need to push a Google Account using their MDM provider, which will re-add their Google accounts to iOS devices using OAuth. Other less secure apps • For any other LSA, ask the developer of the app you are using to start supporting OAuth. • If you use other apps on iOS or MacOS that access your G Suite account information through only a password, most access issues can be resolved by removing then re-adding your account. When you add it back, make sure to select Google as the account type to automatically use OAuth. Scanners and other devices No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails. If you replace your device, look for one that sends email using OAuth. User instructions If you are using an app that accesses your Google account with only a username and password, take one of the following actions to switch to a more secure method and continue to access your email, calendar, or contacts. If you do not take one of the following actions, when LSA access is discontinued after February 15, 2021, you will begin receiving an error message that your username-password combination is incorrect. Email • If you are using stand-alone Outlook 2016 or earlier, move to Office 365 (a web-based version of Outlook) or Outlook 2019, both of which support OAuth access. Alternatively you can use G Suite Sync for Microsoft Outlook. • If you are using Thunderbird or another email client, re-add your Google Account and configure it to use IMAP with OAuth. • If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use only a password to login, you’ll need to remove and re-add your account. When you add it back, select “sign in with Google” to automatically use OAuth

Developer instructions To maintain compatibility with G Suite accounts, update your app to use OAuth 2.0 as a connection method. To get started, follow our developer guide on using OAuth 2.0 to access Google APIs. You can also refer to our guide on OAuth 2.0 for mobile & desktop apps. If you have additional questions or need assistance, please contact G Suite support. When you call or submit your support case, reference issue number 145694552.

I know at the bottom of your documentation for wwSMTP (https://client-tools.west-wind.com/docs/_4nz0smkox.htm) you say "Note that if you have GMail business account (ie. you pay for Gmail) you'll need to enable Enforce Access to less secure Apps for all Users in order to allow external SMTP clients to send email through GMail. This might change for all Gmail accounts in the future." Do you have any plans to support the oAuth required for gmail? That being said, I've heard office365 wants to go this way as well...

Thanks,

Scott

Scott,

wwSmtp supports TLS (1.2) and will support newer versions presumably if that becomes a thing since the code uses the .NET SMTP sending ability. Current Google SMTP access works with it.

oAuth plus an API is not SMTP so no that's not going to work with the SMTP client - since it's not actually SMPT. Looks like they'll have a separate API to do this... You can probably use the wwHttp classes to connect to that API and send email through that, but I don't know.

Frankly sending email through GMail is a bad idea anyway since they have severe restrictions on how many mails you can send and what and how they allow it. Unless you're literally sending a handful of messages it's much better to use some sort of mail service like MailGun (which is what I use) or SendGrid etc. MailGun cost me like a $1 a month or so.

Hey Rick,

Thanks for the info. We're not bulk sending emails out of gmail. Instead, we allow sending emails out of our software so that our clients can email invoices and quotes to their customers. They of course want them coming from their email addresses. A lot of them have enterprise gmail accounts, hence the reason we need to make sure that we can send email through gmail. Gmail going away from SMTP doesn't bode well for us...

As far as oAuth 2 goes, I know oAuth is very tricky in VFP. Is there an easy way to do it via .Net that we can utilize with the wwwDotNetBridge?

oAuth is not really a mechanism for sending emails (or any other operation) per se - it's just the authentication mechanism to get an authentication token you can use to call APIs with.

I haven't looked at how the oAuth flow for Google is set up, but you should be able to do that just fine using wwHttp - the API calls for sure, and the oAuth depends on how they trigger the oAuth interactive Google validation. It may very well be that they support an API specific authentication token, or a way to retrieve one via a separate API call.

I hate Google for this (and many other things). SMTP/IMAP are standard protocols and they're deciding to ditch that in favor of custom APIs which won't work with anything else which is a really shitty thing to do. Just shows you that Google really continues to break the Web any way they can. BTW I use a Google business account as well, but I'm not mailing any of my generated emails through them precisely because of this kind of problem. You can use a different service and get the appropriate email origin information so it doesn't have to come from Google - it has to come from your domain and email address(es).

IAC, this sort of API access is something that has to be built specifically for Google APIs - it won't work with anything else. It's probably not too difficult to set up but I haven't looked into it.

+++ Rick ---