SMTP Auth failures and temporary fix

Greetings, @user198! Thanks for reaching out to us on the Forums! I hope you are having an amazing day! I apologize to hear of the issues you are having with your email client not being able to authenticate off the normal SMTP address. You have come to the right place. Would you be able to let us know what mail client you are using? Also, can you access the Xfinity webmail and go into the options to make sure you have given access to 3rd party mail clients?

This is not a problem with my client or MTA.   As explained above, if I change the authorization credentials on my MTA to use 'smtp-p.gslb4.comcast.com' instead of the published standard 'smtp.comcast.net' it works.  

It would appear that Comcast has a problem with either their TLS certificate or the SMTP DNS entries.  

As your documentation  states: My MTA should be authenticating against 'smtp.comcast.net'  

For your tech support engineers: My MTA is running "Exim version 4.92 #5 built 01-May-2021 09:42:39". 

What changes did Comcast make between December 8th and december 17th ?

Thanx.

Good afternoon,

There have been no server configuration changes made recently. The only recent change was a migration of some of the servers, which is also a pinned message on these forums. 

@user198 

Good morning,

I did additional review into your issue and it appears that there may be an issue in your configuration: all of the messages that are failing authentication are coming in over port 25, not 587, and no auth credentials are being provided.  That being said, we used to allow unauthenticated mail to be sent from within out customer ranges, but that is no longer the case. This may be why it was working previously, even though misconfigured. To note, this change was not made recently and was made over the summer. Reason this is happening at a delay is likely due to the IP coming up for override policy expiration.

Wow! Thanks. That totally worked user198. I was using smtp.comcast.net. I changed it to smtp-p.gslb4.comcast.com and my Microsoft Exchange send connector works. Something went up the spout at Comcast earlier this month. I don't send a lot of email but the last one I sent on the 16th went through. I didn't notice that I could not send until Saturday 25th Dec.

user198: you are not hallucinating. I've been using comcast's authenticated SMTP relay to monitor servers with Nagios and Icinga since somewhere around 2001. Sometime during the first two weeks of December this year, Comcast broke it. I can tell you that if you google for "openssl -nocrlf -s_client -connect" and follow the test procedure, you will see Comcast happily authenticate your credentials, accept your messsage and promptly drop it into the  Luminiferous aether,  never to be seen again. I've been working on trying to solve this problem at my end for 3 days now, testing with Perl Net::SNMPS, sendmail, postfix , openssl and any other tool I can throw at it, to no avail.  It's not your openssl libraries; if you have any recent build of openssl it should just work.

What I've discovered so far is that regardless of relay host name and "third party mailer support" setting on the web login, authentication will fail with any mail transport agent, succeed with openssl s_client and with perl::Net::SMTPS (either with a base64 encoded password with auth type "PLAIN", but the relay engine "conveniently" sends "<<< 500 command unrecognized" when terminating the DATA section with a single dot "." (RFC compliant since the beginning of time) or <CRLF> <CRLF>. This  apparent breakage seems to be a UCE countermeasure that stops all UCE except for what ends up in your own comcast email web accounts (at least in my case). 

I should mention that I have always used port 587/TLS for outbound authentication (for anyone about to start blatering about port 25, which is blocked by ME at the perimiter).  The local machine which uses comcast as a "smarthost" only relays mail from my local devices which are on my internal secure network (for anyone about to start blathering aboiy "open relay").  The local network is protected with an IDS ( and would be  potentially sending intrusion alerts had Comcast not hosed my mail relay interface). I've been doing this professionally since 1998.  Not all people who want SMTP relay service are idiots or UCE bulk spammers.

Here's a little test program that ought to "just work" to relay mail via comcast. The sensitive infomation has been sanitized. It is a proof of concept to prove

something is broken at comcast. The transaction conversation follows this sample code.  

#/usr/bin/perl

use strict;
use warnings;

use Net::SMTPS;
use IO::Socket::SSL;
$IO::Socket::SSL::DEBUG=1;

my($ssl) = 'starttls';
my $smtp = Net::SMTPS->new(
    "smtp.comcast.net",
    Port => 587,
    doSSL => $ssl,
    SSL_verify_mode => 0,
    Debug => 3,
);

$smtp->auth('[my_account]@comcast.net', '[my password]', 'PLAIN');

# '[my password]' is sent to the server as a base64 encoded string

$smtp->mail('[my_account]@comcast.net');
$smtp->to('[my_account]@comcast.net');
$smtp->datasend("A simple test message\n");
$smtp->dataend();  # CRLF

------ conversation follows. Note that I never got any of my test messages. It seems that comcast should let ME decide if the test message is UCE.

They sure DONT if its any of the UCE I've been getting at comcast recently with the subject line /BROOKS BROTHERS/ ..... --------

Net::SMTPS>>> Net::SMTPS(0.10)
Net::SMTPS>>>   IO::Socket::IP(0.21)
Net::SMTPS>>>     IO::Socket(1.34)
Net::SMTPS>>>       IO::Handle(1.33)
Net::SMTPS>>>         Exporter(5.68)
Net::SMTPS>>>   Net::SMTP(3.13)
Net::SMTPS>>>     Net::Cmd(3.13)
Net::SMTPS>>>     IO::Socket::INET(1.33)
Net::SMTPS=GLOB(0x12e1fd8)<<< 220 xxxxx.sys.comcast.net xxxxx.sys.comcast.net ESMTP server ready
Net::SMTPS=GLOB(0x12e1fd8)>>> EHLO localhost.localdomain^M
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-xxx.sys.comcast.net hello [XX.XX.XX.XX], pleased to meet you
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-HELP
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-SIZE 36700160
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-ENHANCEDSTATUSCODES
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-8BITMIME
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-STARTTLS
Net::SMTPS=GLOB(0x12e1fd8)<<< 250 OK
Net::SMTPS=GLOB(0x12e1fd8)>>> STARTTLS^M
Net::SMTPS=GLOB(0x12e1fd8)<<< 220 2.0.0 Ready to start TLS
(....)
Net::SMTPS=GLOB(0x12e1fd8)>>> EHLO xxx.xxxx
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-xxxx.sys.comcast.net hello [XX.XX.XX.XX], pleased to meet you
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-HELP
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-AUTH LOGIN PLAIN XOAUTH2
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-SIZE 36700160
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-ENHANCEDSTATUSCODES
Net::SMTPS=GLOB(0x12e1fd8)<<< 250-8BITMIME
Net::SMTPS=GLOB(0x12e1fd8)<<< 250 OK
Net::SMTPS=GLOB(0x12e1fd8)>>> AUTH-my favorite: PLAIN
Net::SMTPS=GLOB(0x12e1fd8)>>> AUTH-server offerred: LOGIN PLAIN XOAUTH2
Net::SMTPS=GLOB(0x12e1fd8)>>> AUTH-negotiated: PLAIN
Net::SMTPS=GLOB(0x12e1fd8)>>> AUTH PLAIN [BASE64-ENCODED]==^M
Net::SMTPS=GLOB(0x12e1fd8)<<< 235 2.7.0 ... Authentication succeeded
Net::SMTPS=GLOB(0x12e1fd8)>>> MAIL FROM:<xxx@comcast.net>^M
Net::SMTPS=GLOB(0x12e1fd8)<<< 250 2.1.0 <xxx@comcast.net> sender ok
Net::SMTPS=GLOB(0x12e1fd8)>>> RCPT TO:<xxx@comcast.net>^M
Net::SMTPS=GLOB(0x12e1fd8)<<< 250 2.1.5 <xxx@comcast.net> recipient ok
Net::SMTPS=GLOB(0x12e1fd8)>>> A simple test message
Net::SMTPS=GLOB(0x12e1fd8)>>> . // end of message 

So I just retried the above test using "smtp-p.gslb4.comcast.com" as the smtp gateway, same user name, same credentials, two different recipient addresses. One recipient is the sender account at comcast, The other recipient is my google email.

What I get back is 

Net::SMTPS=GLOB(0x1127fd8)<<< 235 2.7.0 ... Authentication succeeded
Net::SMTPS=GLOB(0x1127fd8)>>> MAIL FROM:<xxx@comcast.net>
Net::SMTPS=GLOB(0x1127fd8)<<< 250 2.1.0 <xx@comcast.net> sender ok
Net::SMTPS=GLOB(0x1127fd8)>>> RCPT TO:<xxxx@gmail.com>
Net::SMTPS=GLOB(0x1127fd8)<<< 250 2.1.5 <xxxxx@gmail.com> recipient ok
Net::SMTPS=GLOB(0x1127fd8)>>> A simple test message
Net::SMTPS=GLOB(0x1127fd8)>>> .

As shown. there is no error message from the send attempt. There is also no "Message queued" or "Message accepted for delivery" response from Comcast's smtp gateway.

I'm still waithing more than 12 hours for delivery of previous sent test messages, I'll report back after 24 hours about delivery/non-delivery of *these* test messages.

As others have stated, this breakage appears to have started somewhere in the first two weeks of December. 

If anyone from Comcast actually monitors this thread it would be helpful to get a deterministic answer on the state of this problem.  If the answer is " everyone is out for the holidays" or "everyone is out with Covid", well that's one set of responses to consider.

Either response would seem dubious to those of us who are attempting to monitor equipment status remotely with a small volume of authenticated mail relaying in the interest of reducing social contact. Anyone? 

I am pleased to report that as of 6:00 am EDT (at least until 6:45 am EDT ) the "service unavailable" responses from comcast's authenticated SMTP relay on port 587/TLS appears to be corrected.  The only changes I made to my own local configuration were:

1) to indeed change the smtp server hostname (which is reported elsewhere in the forums, I wont repeat it here, its a little bit like saying "candyman" 3 times into the mirror, for superstitous fear of breaking it ny saying it; I'll let comcast correct thier dated documentation on this subject);

2) to enable transaction logging locally on my own sendmail daemon using the -X switch (be careful with this, it will fill up your disk if you leave it, and it will log EVERYTHING including sensitive information that you shoulnt' leave laying around). I doubt that 2) has any affect on it working.

I still need to find (at both Comcast and Google) the knobs to twist to "unconditionallly whitelist senders" (regardless of DMARC and DKIM signing, even though TLS authenticated transactions through Comcast should be DKIM signed already in transit, and they should instead terminate service to any abusers; I know that they do this, a guy claiming to be from Comcast came to my house 5 years ago and literally CUT THROUGH MY RG6 cable because there was supposedly "a small amount of RF noise on my cable line?").

Test messages I send to myself end up im my "spam" folder (BUT THATS OK, at least they are being delivered now). Messages sent to my google email at the same time have not shown up for an hour so far, that's not reassuring; seems like either Google is wholesale dropping mail (from the same sender) instead of at least diverting it to spam.

If indeed Comcast engineering has fixed this (partially fixed so far, still broken) , my wholehearted thanks to the engineers that got thier hands dirty doing so, especially during a covid outbreak during holiday season.

Listen, I get it. I wasn't kidding when I say I've done this professionally since 1998. I understand what it means to fly across international date lines on short notice, into "friendly" and "not so friendly" countries to climb underneath something heavy to turn one or two screws. For 20 years or so (until recently anyway). 

(Or plug in a cat-6 cable because someone does not know what cat-6 is. Or run a packet sniffer to diagnose a network issue).  I do understand why you have byzantine phone queues and entry level support people between you and the typical residential email user  who dont know what a modem is or much less  who Jon Postel was.

If you are the person or people who fixed this (or backed out what you broke) I really get it. Thanks. 

Check to see if you are using Cloudlflare's DNS anyplace and if that may be the root cause for some of your apparently stuck delivery queue please. One of my associates was having

problems this week with accounts.google.com not resolving (round robin) intermittently; the root cause appeared to be use of 1.1.1,1 as a primary DNS server on one of his wireless routers......

I'm sorry to report:  that after four hours, that of the simulatneous emails that I sent to myself both  at comcast and also to myself at google at 6am EDT , the google emails never arrived. My spam folder at google stands at a total count of 10, where it has been for 30 days.   The contents of my destination address inbox at comcast contain the simutaneously sent messages. (well actually they are in the spam folder but that is a separate issue of comcast email filter failure under a separate issue ticket.) 

Wouldn't it be interesting to discover that Comcast and Google are perhaps  each  simultaneously violating IETF RFCs by blackholing each others bounce messages, and silently discarding (incorrectly percieved) spam messages from each other's mail hosts....?  I hope it's not that ugly.  What has the internet become........

It would really be great if xfinity mail had some advanced tool where low volune senders could examine the outbound mail queue logs for any matching SMTP authentication. So I can see if the messages I sent were stuck in the mail queue at Comcast or being discarded by google. Instead of calling to complain to someone who does not care or does not know.

Wouldn't that be great. Even for the extra $3-$5 / month I'm already paying due to the recent rate increase?  

There are so far no bounce messages in either the inbox or the spam folder of the account which is both the SMTP gateway auth user id, AND the sender address of the source message (which are one and the same email address.)

(This is where I'd expect a bounce message to go, if I were sending it from a MUA, anyway; its where delivery failures usually end up when SMTP relaying is actually working at comcast (as it appears to be partially, as of 6AM according to my relay logs and recieved messages at Comcast, anyway.)

Im also unhappy to report that a similar test message I sent to myself at a corporate email account hosted at Microsoft's office365 two hours ago and just now have not been delivered.

This certainly looks like a breakage at comcast extends to the outbound mail.

My junk mail folder count at office365 stands where it has been for 15 days. I'm still investigating if there's some method to unconditionally whitelist senders at office365 but at the moment it looks like Comcast's outbound mail queue has a severe outbound delivery problem with accepting mail via the authenticated relay (as in "message accepted for delivery") in my local logs) but then  either not delivering it or refusing to DKIMS sign it to circumvent foreign delivery system countermeasures.

(in which case there should still be RFC compliant  bounce messages indicating the cause of the failure).

After 9 hours of confirming via local logging that messages sent to third parties via comcast's authenticated SMTP relay are being accepted for delivery by Comcasts's mail relay, and no evidence that the messages I sent are either bouncing or being rejected, I can only come to the conclusion that Comcast not only silently discards mail, but, due to the lack of response from anybody at comcast, comcast does not care that it is doing so, against any conventional notion of how email hosting is supposed to work.

I've managed to get access to the recipient server logs for a destination address's hosted Microsoft 365 Business Standard mail account, for messages I sent 1/2 hour ago, at 1 minute intervals for a count of 10. There is no evidence in the destination server's logs that a delivery attempt was even made. I'm still waiting for other accepted messages to be delivered to other third party (non-comcast) email destinations that I control that were sent at 6am.

My advice currently to any comcast customer who depends on reliable delivery of email, is that even if you use a "conventional" mail user agent (read Outlook or the ugly xfinity web based MUA) that you should be prepared for breakages that cause your mail to dissapear silently, with none of the IETF RFC compliant mechanisms that are intended to notifiy you of failure or the reason for it. 

You should also expect no appropriate activist  response, or, for that matter, any reasonable assistance  from Comcast for a service that you pay for and don't recieve. 

You should expect, however, apparent total indifference,  spam filters that are blind to massive amounts of UCE, and spam countermeasures that are  impossible to bypass for senders that you WANT to recieve, such as the email address for the account to which the recipient address is attached.

You should expect eventual breakage of the things that *do* work now, such as your pointy-mashy Outlook or Thunderbird mail  client, when someone at comcast decides to ignore breakage and decide that you, the poor end user who is dependent on it to work, are not worth the trouble as long as you keep paying what you pay for month.

You should expect all manner of unneccesary two factor authentication prompts and secondary email address requests, for mail address logins that are tied to your primary account, where the email contact information for the primary account cant be accepted for a secondary account "because it is already in use for another account". Yes. Your own other account login under the same billing is where it is in use. 

You should expect lengthy circular email queue prompts that force you to wade through voice prompts for 10 or 15 minutes just to (if you are lucky) talk to a person, who will be totally clueless about any problem you are trying to solve.

When you finally reach someone at the "corporate office" to complain, they will offer to send a technician to your house, to solve a problem that is clearly happening at thier own mail gateway downtown.

Any complaint you register with Corporate will be interpreted as an attempt to get a support representative fired, perhaps for some percieved PC nonsense, when in fact your complaint will be that its impossible to get phone support from somebody who has at least been trained and not reading from some support script.

I began to have this problem on December 28 around 1300 EST.  The OP's workaround of picking a particular SMTP server in place of smtp.comcast.net results in the connection timing out (as if the hostname generated and redirected to in place of smtp.comcast.net is one time use only or something).  For me the issue continues to be with authentication rather than messages being accepted but not delivered.

This message will probably be filterd by Comcast since it competes economically with the service that they refuse to support now, but check out dynu.com if you  are willing to pay $20 more a year to just  make the problem go away. dynu's support response cycle is a little slow, perhaps due to COVID or the holidays (at more than 24 hours per support response in some cases, and the DMARC records are a little clunky and non-self service), but the service DOES work and they, unlike comcast, DO respond eventually.

Despite the additon of  DMARC records, the totally useless UCE countermeasures at COMCAST and GOOGLE, which let all manner of REAL UCE pass, will block the DMARC- marked emails relayed by DYNU, so your recipients will need to take agresssive effort to bypass SPAM filters for messages with the most innocuous content (like an RFC 1918 IP nunber and a network event in plain text non-html format, 10 lines or so), but at least your relayed message will eventually arrive.

There is apparently no mechanism now to circumvent the (oxymoronic) notion of Aritficial Intellegence when it comes to email filtering. Once a message was determined to be SPAM / UCE (regardless of content) you apparently cannot unconditionallly mark that sender's mail to me immune from being learned as junk mail. Even if you can force the messsage to be bypass the junk mail folders, nowadays web UIs wil still display an ugly banner indicating that despite the recipients choice, the message is still SPAM. 

In the old days, when UCE filtering was done with Spamassassin (which actually worked, when trained right) there was a directive ACCEPT_AND_NO_MORE_FILTERING. No such thing apparently exists anymore. 

I'm shopping for a new ISP.