This morning, one of my comcast email accounts began rejecting emails sent by Pegasus
{WinPMail version: Version 4.80.1028, Jan 16 2022, build ID 1028
IERRenderer 2.6.6.0}.

Error Message: "550 5.1.0 Please ensure your email address and authenticating user match when sending."

In discussion with Comcast Tech support (yes, you can get through to them if you hold your tongue right) we determined:

1 - it only effects one of my Comcast email accounts (the other one I use only rarely - it's my contact account for my own servers - it still functions)

2 - It's only if I try to access that account via Pegasus for sending email - I can use Comcast's webmail interface fine.

3 - I can retrieve email from that sending-blocked account using Pegasus.

4 - I have changed nothing with regards to this account set up or configuration on Comcast or Pegasus for at least 5 years - last change involved new "ports" (465/995) for security.

Comcast Tech support reports that it is indeed OLATH-2 related, and suggested they are going to try to "copy" the configuration "from the one account I mentioned that still works over to the account that is failing, since I am an authenticated customer account."

"They will call me back in an hour or so.."

Stay tooned..

Confirmed OLATH2 ...

Posted "just for the record".

TCP Log from failed email send via comcast: File: TCP-221118-1417-0.smtp

14:17:38.272: --- 18 Nov 2022, 14:17:38.272 ---

<snip>

14:17:39.789: >> 250-AUTH LOGIN PLAIN XOAUTH2<cr><lf>
14:17:39.789: >> 250-SIZE 36700160<cr><lf>
14:17:39.789: >> 250-ENHANCEDSTATUSCODES<cr><lf>
14:17:39.789: >> 250-8BITMIME<cr><lf>
14:17:39.789: >> 250 OK<cr><lf>

<snip>

14:17:40.159: >> 235 2.7.0 ... Authentication succeeded<cr><lf>

<snip> (Oops- OLATH2 didn't like that authentication after all..)

14:18:00.302: << QUIT<cr><lf>
14:18:00.317: 26: SSL read returned zero (socket was closed)
14:18:00.317: >> (buh bye!)
14:18:00.317: [*] OpenSSL secure session normally terminated.
14:18:00.317: --- Connection closed at 18 Nov 2022, 14:18:00.317. ---
14:18:00.317:

successful send account log: File: TCP-221118-1422-1.smtp (apparently no OLATH2 implementation yet)

14:22:18.751: --- 18 Nov 2022, 14:22:18.751 ---
14:22:18.751: Connect to 'smtp.{redacted}', timeout 60 seconds.
14:22:19.932: [*] SSL/TLS session established

<snip>

14:22:20.456: >> 250-PIPELINING<cr><lf>
14:22:20.456: >> 250-PIPE_CONNECT<cr><lf>
14:22:20.456: >> 250-AUTH PLAIN LOGIN<cr><lf>
14:22:20.456: >> 250 HELP<cr><lf>
14:22:20.456: << AUTH LOGIN<cr><lf>

<snip>

14:22:20.704: >> 235 Authentication succeeded<cr><lf>

<snip> (and we're all good here..)

14:22:20.936: << X-mailer: Pegasus Mail for Windows (4.80.1028 )<cr><lf>
14:22:20.936: << Content-type: text/plain; charset=US-ASCII<cr><lf>
14:22:20.936: << Content-transfer-encoding: 7BIT<cr><lf>
14:22:20.936: << Content-description: Mail message body<cr><lf>
14:22:20.936: << <cr><lf>
14:22:20.936: << test<cr><lf>
14:22:20.936: << .<cr><lf>
14:22:21.058: >> 250 OK id=....... <cr><lf>
14:22:21.074: << QUIT<cr><lf>
14:22:21.407: >> 221 closing connection<cr><lf>
14:22:21.438: [*] OpenSSL secure session normally terminated.
14:22:21.438: --- Connection closed at 18 Nov 2022, 14:22:21.438. ---
14:22:21.438:

I wonder if this means exactly what it says. Either thee "My internet email address" configured in Pegasus Mail does not match the one being used in the authenticating credentials or the authentication username is not an email address.

IMPORTANT: Change your password(s)! The logs you posted contained both your authenticating username and password. They are encryped in Base64 which is easily decoded with online tools.

Thanks Brian - yea, passwords changed... (and I was finally allowed to go back and edit that stuff out. For some reason I couldn't earlier.. )

AND... the cause has been discovered and corrected. And yes you are correct..

Here's what I did to cause it, and correct it..

I have 3 email accounts on comcast - my main account, and two "additional accounts".

I never use the main account email for receiving email - one of the other Email accounts is used only for my webserver contacts, and the third I use rather regularly.

But, years ago, all three were set up in Pegasus to use the main account's SMPT credentials for sending emails..

With OLATH-2 implemented, that is no longer permitted. To "fix" the problem, each account must send through it's own account using its own credentials (I assume the sent-from/reply-to must match the credentials given .. that old smtp "feature" has been closed).

In other words, it looks like Pegasus "shared definitions" for POP3/SMTP in internet email sending is going to become "non-gratis" as OLATH-2 rolls out..

"Self-inflicted headwounds.." (It's been so long since I set it up that way I don't even remember why I did it now.. )

It's been so long since I set it up that way I don't even remember why I did it now..

Ah - now I remember .. my "redirect" email addys.. Comcast doesn't appear to offer them, so no skin off their nose to require the From/Send-to addy to match the account credentials. Alas, redirect/alias addys don't have credentials to match.
Now, my alias accounts are all on my own servers and within the same domain, although they don't have to be - or rather, didn't have to be before. I just carried over the "practice" of a single sending account on my server when using comcast.

[Another crazy implementation - comcast allows each "master" account up to 10 email "sub-accounts", but now won't allow you to use the same phone number or external email for two different accounts for log-in authentication - set the authentication 'call back' for one account and it's erased from any other account as the contact.]

Anyway, it's going to be interesting to see what my own platforms' hosts smtp/pop3 email server does with "OLATH-2" compliance, and if it's going to end up doing away with aliasing. It could force me to convert the redirects to accounts, but at least Pegasus allows selecting which account 'identities' to check (or not) when receiving emails.

Dave is correct, OLATH2 is pretty ambiguous and open to interpretation, and we're going to have to deal with everybody else's various interpretations and implementations, individually. Further misfortune, the tech support folks on those various platforms, if you can even reach them, because of their own security concerns they won't tell you what exactly their security implementations are (so you can troubleshoot why something is no longer working and 'comply' ), assuming they have any idea either.

Onward through the fog..