Looks like the app password may still work. The mail logs had more info
"
"ERROR","Thread-186806","09/16/2025","19:18:03","mail","javax.mail.AuthenticationFailedException: 534-5.7.9 Application-specific password required. For more information, go to
534 5.7.9 https://support.google.com/mail/?p=InvalidSecondFactor 00721157ae682-72f76238477sm44612297b3.3 - gsmtp
So it looks like the link to get the app passwords has changed to
(https://myaccount.google.com/u/1/apppasswords)
And once the app password was used, it worked perfectly, no oauth required.
Of course, that isn’t going to solve the long term problem of building OAuth at some point… But the can still appears to respond to a kick…
This is one reason i’d love to start a community discussion around moving to a new mail connector in admin. One that handles smtp/imap/oauth/headers and manages in and outgoing mail connections in mail source, along with introducing the mailsource attribute for nominating a mail server for cfmail/cfimap/etc
modernisation of this area is pretty important, and is only going to get more complex. It would be great if we had central management of the ‘email’ (not mail) component that could allow extensions to provide abstractions of an interface for email incoming/outgoing/bounces/dmark notifications/tracking webhooks… is it time for lucee to be cutting edge with email?
Same issue has been ignored for postmark and others for a few years now. Maybe it’s time to innovate here? #discuss
The problem is that as time has progressed and there hasn’t been an industry-wide effort to fix the issue, every vendor has their own implementation on how to send mail.
Google’s GMAIL is using oAuth.
Microsoft is pushing folks to Graph API for O365 and on-prem.
AWS is doing IAM authentication (non-SMTP, API calls only)
Mailgun and others are doing their own HTTPs/API calls
There won’t be a single solution or way to develop a single set of tags that will do more than a single vendor, since all of them are /so/ different…
Ouch now you’ve got me worried about the setup I’ve been using for years, seemingly with no issues, but now worthy of reassessment:
In terms of email deliverability compliance (SPF, DKIM, DMARC, etc) the Return-path header is of primary importance.
I send thousands of emails every week through my own Exim server (so I control every aspect of config and log access) with Reply-To headers set to sender.example@gmail.com while From is generally something like news@mydomain.com and Return-path is example-batch-ID@news.mydomain.com with a catch-all on that subdomain which redirects to bounce@mydomain.com.
In the recipient’s inbox in most email apps and webmails, the sender is identified by their name (the double-quoted part of the From header) instead of the From address being displayed, which avoids confusion. And of course because of the Reply-To header, the original From is also not displayed in any replies.
I have a cron job that monitors bounce@mydomain.com (using cfimap woohoo!) and spam is only ever the reason when it’s due to email content or the recipient has misconfigured forwarding for their custom domain.
OTOH, my experience with mega-corporations being what it has been, I would not be at all surprised if the Reply-To being different than From – though completely legit – might increase the risk of Gmail silently dropping those into spam folders instead of bouncing. With their Google Workspace service and market share they already have the financial incentive of providing the solution to a problem which … they might have created?
I’m not aware of specific evidence for Reply-To on its own being a spam filter trigger, but if such documentation exists somewhere, please do share!
I think using a local MTA which Lucee sends to via standard SMTP which then can forward on your behalf using whatever auth variant the upstream provider might be a good solution here?
