Postie going to be able to use modern Auth?

[tjthorson]

Seems all my scripts using postie that are in O365 are breaking.  microsoft seems to have removed Basic Auth - even if you enable 2FA and use an app password.  Any ideas besides redoing everything to use a GMAIL account?  MS says I need to "use Modern Auth" - any plans to add that into Postie?  (please!)  or I guess -if Im doing something wrong, would appreciate any help.  My settings are always using port 587 and TLS.

[td]

There are no plans to add Oauth2 to the Poistie extender. In order to do that you, the scriptwriter, would have to submit a compiled script to MSFT for approval. If you did get approval, you would need to pay MSFT a monthly or yearly fee for the privilege.  ILC LLC gets around the problem by using another email provider for sending script-generated email messages.  It is not very expensive, is not Gmail, and uses several international standards like DMARC on its SMTP servers. Our email sent via this provider has a better rate of acceptance than our email sent using MSFT's cloud-based 365.

[kdmoyers]

Tony, can you suggest some web search terms that are likely to produce a list of such services?

a couple I came up with:
"email provider -google -microsoft" or "alternative to O365"

I think this is a topic of increasing interest.

(I'm using fastmail.com and like it, but have not used their SMTP yet)

[td]

Maybe add a term like reviews or ratings to your search phrase.  Look for Email service providers that support the SPF, DKIM, and DMARC protocols.  If you are using your own domain, you need to have administrative access to your DNS server or DNS service provider account to add supporting records to the domains that you use for sending email messages. Generally, any good email service provider will supply instructions and even create the DNS records you need to add.

Big tech never ceases to amaze when it comes to finding creative ways to extract money from their user base. Whenever reading terms like "modern" and "secure" know what is coming next.

[td]

Also neglected to mention that MSFT's Office 365 has its own special protocol for sending email messages. Underneath the hood, it is still SMTP but they require you to use their proprietary cover protocol. This protocol is HTTP based with a little .Net sugar on top.

[stanl]

Also neglected to mention that MSFT's Office 365 has its own special protocol for sending email messages. Underneath the hood, it is still SMTP but they require you to use their proprietary cover protocol. This protocol is HTTP based with a little .Net sugar on top.

Like to here a little more about this. We have Office 365 and I can still send emails/attachments/inserted Excel ranges with CreateObject("Outlook Application").

[td]

Outlook is an MSFT application what more is there to say? Microsoft 365 consists is in part a collection of web services including email transport. You should find the documentation on MSFT's main and Github sites. You can log on to your Azure account and find more marketing-based documentation as well as some slightly useful tutorials and guides.

[td]

Forgot to mention this Tech Database article based on a script you may have written long ago:

https://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/dotNet/EWS/Mail+Simple~EWS~Email~Message.txt

Haven't tried it with Microsoft 365  but notice the comment at the top of the script.

[td]

One last? comment. MSFT proprietary email transport with OAuth2 support is part of the Graph API. You can search on "Microsoft Graph API" for details.

[tjthorson]

Thank you all for the replies - I figured that was the case, just have to convince the client....  :)

[td]

While moving to a different email service provider was a much better option for ILC LLC, as Stan pointed out, you could always try using Outlook with WinBatch COM Automation. Of course, you would need to have a newer version of Office with Outlook installed on any systems running the script.

An incomplete example:

Code (winbatch) Select Expand

recip="<recipient email address goes here>"
AttachmentPath=""
objOutlook = ObjectCreate("Outlook.Application")
objOutlookMsg = objOutlook.CreateItem(0)
objOutlookRecip=objOutlookMsg.Recipients
objOutlookRecip.Add(Recip)
objOutlookMsg.Subject = "Test"
objOutlookMsg.Body = "This is a test":@CRLF
objOutlookMsg.Send

[stanl]

Thanks Tony;


One of my assumptions is most users now have Office installed :'( .  I have scripts to

   
• Create Excel file from db data and format it
• copy used range to clipboard
• Open instance of Outloook with subject/recipients
• Insert used range into body
• Include corporate signature
• add .xlsx if needed
• send

currently working with how to add text before dropping in the used range screenshot. Always seems to come at the end. ???

Code (WINBATCH) Select Expand



;assumes you have placed Excel used range to clipboard
;xl.CutCopyMode = 1
;ws.UsedRange.Select()
;xl.Selection.CopyPicture(2,1)


oOutlook =CreateObject("Outlook.Application")
oMailMsg = oOutlook.CreateItem(0)
oMailMsg.GetInspector.Activate()
sSignature = oMailMsg.HTMLBody
oMailMsg.To = Recip  ;who is it going to
oMailMsg.Subject = "My Email Message"
oMailMsg.HTMLBody = @CRLF : cBody : sSignature
oMailMsg.Getinspector.WordEditor.Range(0,0).Paste()
oMailMsg.Attachments.Add(cXLS) ;if attaching file
oMailMsg.Send()


[td]

I don't know how much longer your assumption will remain valid for many entities. MSFT is increasingly moving toward cloud-only based Office. I use both versions on one machine but on all my other machines Office is strictly cloud-based.

[stanl]

I don't know how much longer your assumption will remain valid for many entities. MSFT is increasingly moving toward cloud-only based Office. I use both versions on one machine but on all my other machines Office is strictly cloud-based.

Our 365 is cloud-based, but it seems the basic COM Outlook.Application still works, albeit most of the emails I prepare through script are sent within our domain. On another topic, it appears that VBA macros don't function so well on the cloud and MSFT is pushing power query [now called Get and Transform] and Mcode. You look at the drop-downs in 365 and it now handles Json, PDF and even Hana database. And they throw out Power BI which competes well with Tableau... all of which the cynic in me promotes hardware with more memory and capacity :-\ .....


I have personal surface-pro and Win10 laptop, both of which function well but neither can be updated to Win11... but my corporate laptop is scheduled for deprecation at end of 2023.

[td]

Office 365 can be a highbred application suite with both local executables and cloud-based "app" functionality with cloud storage. However, the version I am referring to and using has no local presents including no local Outlook.  MSFT is slowly pushing in that direction in a lot of areas. All the better to surveil users with...