IMAP access to Comcast email

Post by Adam H. Kerman
Yesterday, Comcast changed to Web site path to check email. The
deep link is now https://connect.xfinity.com/appsuite/ although
the previous deep link redirects.
I haven't been able to access my inbox via IMAP. I don't even get
the "temporarily blacklisted" error message; the client just
hangs. I looked at the setting page; settings have not changed. I
did change from the Comcast ID to the email address as username in
case that made a difference, but it didn't.
Was anyone able to access Comcast email yesterday or today via
IMAP?

I've been retrieving IMAP email all along with no problems.

Adam H. Kerman

2023-09-16 22:21:19 UTC

Post by Nil

I've been retrieving IMAP email all along with no problems.

Thanks

I don't want to call them. They'll just tell me to reset the cable
modem.

VanguardLH

2023-09-16 22:58:17 UTC

Post by Adam H. Kerman
Yesterday, Comcast changed to Web site path to check email. The deep
link is now https://connect.xfinity.com/appsuite/ although the previous
deep link redirects.
I haven't been able to access my inbox via IMAP. I don't even get the
"temporarily blacklisted" error message; the client just hangs. I looked
at the setting page; settings have not changed. I did change from the
Comcast ID to the email address as username in case that made a
difference, but it didn't.
Was anyone able to access Comcast email yesterday or today via IMAP?

Can you sucessfully login to look at your e-mails using their webmail
client? You mentioned the blacklisting error you had before which
sounds like they considered you were abusing their personal-use quotas,
and temporarily locked up your account for maybe a day. I supposed it
that triggers often enough that they may decide to suspend your account.
Using their webmail client will see if you can still get in.

My local e-mail client (eM Client) is configured to use IMAP to access
my Comcast e-mails. I'm not getting errors or hangs on polling my
Comcast account via IMAP. I sent a test message from my Hotmail account
to my Comcast account. It showed up in a few seconds.

How big is your Comcast mailbox? I think they have a quota on it. In
eM Client, when I select Properties on the Comcast account, there's a
Quota tab which shows I've used 99 KB of 10.1 GB. I get extremely
little e-mails to my Comcast account. I never use it anywhere other
than with an e-mail aliasing service (Anonaddy), so typically the only
e-mails there were redirected through the aliasing service (which is not
just forwarding, but replies go back through Anonaddy, so the headers
look like my reply originated there). If an alias gets abused, I kill
it. Right now, there's only 1 surviving aliases in my Anonaddy account.
I wasn't aware there is a storage quota on Comcast e-mail account. So,
I did a search, and found:

https://www.xfinity.com/support/articles/xconn-email-storage-limit

If you run out of quota, no more e-mails come into your account (sender
gets an error), and you cannot send more e-mails out. You need to clean
out the crap to make more room.

Adam H. Kerman

2023-09-17 00:47:47 UTC

Post by Adam H. Kerman
Yesterday, Comcast changed to Web site path to check email. The deep
link is now https://connect.xfinity.com/appsuite/ although the previous
deep link redirects.
I haven't been able to access my inbox via IMAP. I don't even get the
"temporarily blacklisted" error message; the client just hangs. I looked
at the setting page; settings have not changed. I did change from the
Comcast ID to the email address as username in case that made a
difference, but it didn't.
Was anyone able to access Comcast email yesterday or today via IMAP?

I've talked about this many times over the years. You don't need to
guess. The host that gets temporarily blacklisted isn't on my home
network. My home network, from which I might use Web mail, is not and
never has been blacklisted.

I said specifically that this is NOT the usual blacklisting error; the
client just hangs.

Post by VanguardLH
. . .

VanguardLH

2023-09-17 01:54:56 UTC

Post by Adam H. Kerman
Yesterday, Comcast changed to Web site path to check email. The deep
link is now https://connect.xfinity.com/appsuite/ although the previous
deep link redirects.
I haven't been able to access my inbox via IMAP. I don't even get the
"temporarily blacklisted" error message; the client just hangs. I looked
at the setting page; settings have not changed. I did change from the
Comcast ID to the email address as username in case that made a
difference, but it didn't.
Was anyone able to access Comcast email yesterday or today via IMAP?

Sorry for bruising your ego, but NOBODY on Usenet is important enough
for me to compile bios of their past experiences or search through all
their past posts. You are familiar with your setup. No one else is.

You never mentioned if you are attempting IMAP access to Comcast from
home, work, or somewhere else. All anyone knows is you are using IMAP
/somewhere/ to access Comcast's IMAP server.

Since Comcast is still somehow implemented in your non-home setup, or
wherever, you still run into the storage quota of 10 GB at Comcast. Did
you check that?

Post by Adam H. Kerman
I said specifically that this is NOT the usual blacklisting error; the
client just hangs.

Blacklisting does not always generate an error message in the local
client. Blacklisting is not always blocking access. It could also be
the account got suspended. I'm not sure a suspended account will
generate any message back to the client. It's suspended. The client
can't use that account. Could be a temporary suspend which often takes
24 hours to clear.

Does your e-mail client have a log you can enable to see at which client
issued IMAP command the server then no longer responds?

If the issue is with retrieving a particular message, use the webmail
client to see what is sitting in your online Inbox. I have seen where a
corrupted messages confuses the server. You use the webmail client to
read the message, if possible, and then delete it. Then try your IMAP
client.

If the client is hanging at the initial handshake to establish an IMAP
session, do you see Comcast's server response when, inside a command
shell, you telnet into their server?

telnet imap.comcast.net 143

The server should respond with an OK message followed by keywords that
reflect the capabilities of that server.

Adam H. Kerman

2023-09-17 04:27:26 UTC

Post by Adam H. Kerman
Yesterday, Comcast changed to Web site path to check email. The deep
link is now https://connect.xfinity.com/appsuite/ although the previous
deep link redirects.
I haven't been able to access my inbox via IMAP. I don't even get the
"temporarily blacklisted" error message; the client just hangs. I looked
at the setting page; settings have not changed. I did change from the
Comcast ID to the email address as username in case that made a
difference, but it didn't.
Was anyone able to access Comcast email yesterday or today via IMAP?

I didn't ask you to guess. I said specifically that I DIDN'T get the
"temporarily blacklisted" error message but that the mail client just
hung. I didn't require you to offer me 500,000 words on why I might have
been blacklisted given that that WAS NOT the issue.

No, I don't expect you to recall what I'd written about in the past. I
do expect you to read what I had just written in the precursor article.

Post by VanguardLH
You never mentioned if you are attempting IMAP access to Comcast from
home, work, or somewhere else. All anyone knows is you are using IMAP
/somewhere/ to access Comcast's IMAP server.

That is correct. I didn't say it. What need was there for you to
speculate?

Post by VanguardLH
Since Comcast is still somehow implemented in your non-home setup, or
wherever, you still run into the storage quota of 10 GB at Comcast. Did
you check that?

There aren't that many email messages, perhaps a hundred. The account is
used mostly for service-related email messages.

Post by Adam H. Kerman
I said specifically that this is NOT the usual blacklisting error; the
client just hangs.

I commented that I had Web mail access. It was in the very first
paragraph. That's how I learned that the deep link to check Web mail had
changed. Will you knock it off already?

Post by VanguardLH
Does your e-mail client have a log you can enable to see at which client
issued IMAP command the server then no longer responds?

Yes, I can turn on logging. I didn't bother to.

If it lasts much longer, I'll have to do that.

Right now, I had a brief power brownout that somehow affected all of my
Comcast services. Even DVR service went into "stolen box" mode, which
happened due to the power outage reset during the cable outage.

VanguardLH

2023-09-17 07:12:24 UTC

Post by Adam H. Kerman
There aren't that many email messages, perhaps a hundred. The account is
used mostly for service-related email messages.

I didn't find a FAQ article on maximum size for a message. It's not the
count of messages. It's their aggregate size. As mentioned, their
webmail client will show how much storage is currently consumed. Click
on the gear icon, and one of the drop-down list entries is quota
consumption.

Post by Adam H. Kerman
I commented that I had Web mail access. It was in the very first
paragraph. That's how I learned that the deep link to check Web mail
had changed. Will you knock it off already?

Reread your first paragraph. Why that was there was unclear. You do
not say you used their webmail client. Since you have used it, your
account isn't locked out or suspended.

First you lambaste me for guessing. Then you lambaste me for not
guessing (what you meant to say in the 1st paragraph).

Post by VanguardLH
Does your e-mail client have a log you can enable to see at which
client issued IMAP command the server then no longer responds?

Yes, I can turn on logging. I didn't bother to.
If it lasts much longer, I'll have to do that.
Right now, I had a brief power brownout that somehow affected all of my
Comcast services. Even DVR service went into "stolen box" mode, which
happened due to the power outage reset during the cable outage.

Yikes. Looks like the gear didn't come back to a good state. I and Nil
say we have IMAP access now. You might have to do a reset, or worse do
a re-provision.

If you try a restart on the cable modem, do not hold down the recessed
button for more than 10 seconds as that, according to them, does a reset
which then may require a re-provision of the cable modem. A restart
takes about 10 minutes for the cable modem to come back up fully. A
reset could take over half an hour. Just press and quickly release the
reset button (usually through a pin hole in the back, so you'll need to
unbend a paper clip to poke through).

You can also use their app to have their end send a reset to your cable
modem. A lot faster than calling them up. Even faster than wading
through their ridicuously insane convolute prompting system. The time
to reset the cable modem, and wait for it to come completely up, is the
same whether you call them, or use the app.

https://play.google.com/store/apps/details?id=com.xfinity.digitalhome
Services button (bottom navbar) -> Internet -> Troubleshoot
Restart your gateway.

Another way to restart the cable modem is to use a web browser to
connect to 10.0.0.1, or whatever is the IP address for the gateway. You
can run "ipconfig" in a command shell to get the gateway IP address.
The cable modem has its own internal web server. After logging in,
there should be an option to restart the modem perhaps under a
Troubleshooting section.

For some reason they never divulge, or refuse to acknowledge they do not
know and are just following some canned recommendation, Comcast techs
want you to use their app instead of pushing the reset button on the
modem, or logging into the modem's internal web server.

Nil and I have IMAP access, but likely we're using servers regional in
our area. Comcast has many regionally dispered servers for load
balancing. Same for their DNS servers. We might be working okay where
we are, but not you were you are. All of us might be using the same
FQDN for the server name, but their DNS servers might be giving us
different IP addresses based on region. Did you check if telnetting got
a response from whichever IMAP server to which you end up connecting?

I don't use Comcast's DNS servers. Well, I do indirectly. IPv4 and
IPv6 in my Windows is configured to use, in order of priority:

1.1.1.1 Cloudflare
208.67.222.222 OpenDNS
8.8.8.8 Google
10.0.0.1 cable modem

The cable modem is configured to use the upstream DHCP server (Comcast)
to get its WAN-side IP address which also means the cable modem
(10.0.0.1) will use Comcast's regional DNS server. When I do an
"nslookup imap.comcast.net" which ends up using Cloudflare's DNS server,
by default, I get a slew of IP addresses (both IPv6 and IPv4). When I
run "nslookup imap.comcast.net 10.0.0.1" (to have the router in the
cable modem simply hop the DNS lookups to the upstream server which is
whatever Comcast gave my router), I get a different list of IP
addresses. Which DNS server I end up using decides what IP addresses
get returned for the host lookup.

I don't know which DNS server Nil is using, nor which one you use. I
changed my DNS config a long time ago when Comcast was having too many
DNS outages per year. They could also have IMAP server outages, but the
one I end up reaching could be a different one than you try to reach.

If the IMAP server were down, I would expect the e-mail client to issue
a connection error (host not found). However, from your description,
looks like the IMAP server is reachable, but is not responsive, or so
overwhelmed with traffic that it is excruciatingly slow.

If you couldn't reach the server, like it was down, I would think your
client would issue a "not found" error. If the server accepted your
connection request, but was severely slow or unresponsive, I would think
your client would eventually issue a timeout error.

It is also possible there is such a huge message sitting in the Inbox
(or other synch'ed folder since this is IMAP) that it takes forever to
download. E-mail servers are nowhere near as fast as file server, plus
each connection is deliberately throttled, so all concurrent users get
some performance. Not only are e-mail connections slow, all e-mail is
sent as ASCII text which means attachments, like binaries (images,
videos, etc) get converted into a MIME text block which is, at least,
1.5 times the size of the original file. Did you use the webmail client
to review the IMAP folders (to which you client subscribes) to check for
some inordinately sized message? Not all, but some webmail clients will
show sizes of messages. I don't see a column in Hotmail's webmail
client showing message size, but I didn't look very hard since I rarely
use a webmail client. I sent a test message from my Hotmail account to
my Comcast account. Comcast does have a column showing message size in
their webmail client.

I've run into e-mail clients that don't use IMAP PUSH. They still rely
on mail polls. The problem is that a message could be so huge that it
takes longer to download than the polling interval. While the huge
message is getting downloaded, the next mail poll comes along, the
session gets restarted, and the huge message downloads anew. The result
is the huge message never gets downloaded, because it got aborted by the
next mail poll, resulting in no further messages getting downloaded.
You have to use the webmail client to get rid of the huge message (read
it, save the attachment to a local file, and delete the huge message),
or increase the mail poll interval configured in the local e-mail client
(to keep it from aborting a download in progress). With a mail poll
shorter than the time to download a huge message, the message download
gets aborted by the next mail poll, and you start all over again, but
keep getting stalled on that huge message.

Adam H. Kerman

2023-09-17 15:59:38 UTC

Post by Adam H. Kerman
There aren't that many email messages, perhaps a hundred. The account is
used mostly for service-related email messages.

I didn't find a FAQ article on maximum size for a message. It's not the
count of messages. It's their aggregate size. . . .

I don't want to talk about this. Your guess was wrong. For the 2,723rd
time, your guess was wrong. You aren't being helpful by making guesses.

You aren't listening. The email account is not suspended for being over
quota. It's not suspended AT ALL.

Reread your first paragraph. Why that was there was unclear. You do
not say you used their webmail client.

It doesn't matter at this point that you didn't infer I had Web mail
access when I stated that the deep link for Web mail access had changed.
I don't know how I could have made that discovery lacking Web mail
access. In each subsequent followups, I stated that I had Web mail
access.

Post by VanguardLH
Since you have used it, your account isn't locked out or suspended.

Nice of you to acknowledge the obvious.

Post by VanguardLH
First you lambaste me for guessing. Then you lambaste me for not
guessing (what you meant to say in the 1st paragraph).

My first paragraph required no guessing at all about issues I had not
mentioned, just a reasonable inference that I had Web mail access because
there was would have been the most obvious way to learn that the deep
link used to access Web mail had changed.

Post by VanguardLH
Does your e-mail client have a log you can enable to see at which
client issued IMAP command the server then no longer responds?

Yes, I can turn on logging. I didn't bother to.
If it lasts much longer, I'll have to do that.
Right now, I had a brief power brownout that somehow affected all of my
Comcast services. Even DVR service went into "stolen box" mode, which
happened due to the power outage reset during the cable outage.

Yikes. Looks like the gear didn't come back to a good state. I and Nil
say we have IMAP access now. You might have to do a reset, or worse do
a re-provision.

Subsequently Comcast services were restored. DVR services were restored
to the two boxes a few minutes after cable was restored once the boxes
were able to "phone home".

The Comcast Web site now has a status check tool which I am able to use
WITHOUT installing the Comcast app on my smart phone, something I refused
to do. It's more straight forward to use than the tool they had prior
to the COVID shut down before their major Web site reorganization.

Using the tool from a foreign network requires that I sign in. Using the
tool on the Comcast network requires no sign in, just confirmation of
the address. I supposed I'd have to sign in if I were on the Comcast
network but not physically using the specific Comcast cable modem I'm
renting.

From the tool, the cable modem is addressable but the two DVRs aren't.
Now, the DVRs were meant to be addressable and have MAC addresses. I
believe some of the additional ports the manufacturer built into them (that
Comcast deactivates) were meant to allow the box to also act as a cable
modem and provide Internet access, but Comcast never used those features.
I suspect the DVRs could have been addressable with IP addresses if
Comcast had set it up that way.

Anyway, the tool isn't designed to interface with the head end equipment
that serves the television side. I tested by resetting both boxes again
(unplugging them) after the outage ended but the tool cannot address
them.

I don't have a separate router at present. I'm using the one built into
the cable modem. I couldn't use my home network during the cable outage
either, something I anticipated would happen.

Post by VanguardLH
If you try a restart on the cable modem, do not hold down the recessed
button for more than 10 seconds as that, according to them, does a reset
which then may require a re-provision of the cable modem. A restart
takes about 10 minutes for the cable modem to come back up fully. A
reset could take over half an hour. Just press and quickly release the
reset button (usually through a pin hole in the back, so you'll need to
unbend a paper clip to poke through).

Sure. I've been through that with other cable modems I've rented from
them in the past. As the cable modem (which is also an eMTA for
telephonhy) doesn't have battery, I reset it by unplugging it from the
house current. I did that during the cable outage and didn't have to do
it again once the outage ended.

Post by VanguardLH
You can also use their app to have their end send a reset to your cable
modem. A lot faster than calling them up.

See the earlier paragraph. I can now access the tool through their Web
site. I refused to install the app on my smart phone.

Post by VanguardLH
Even faster than wading through their ridicuously insane convolute
prompting system. . . .

I agree. Comcast's IVR is vile. It's gotten much much worse over the
years; they keep adding layers of menus to it.

Post by VanguardLH
Another way to restart the cable modem is to use a web browser to
connect to 10.0.0.1, or whatever is the IP address for the gateway.

Not during a cable outage as I have no LAN lacking a separate router.
But yes, I'm using the default IPv4 address on the LAN side.

Post by VanguardLH
You can run "ipconfig" in a command shell to get the gateway IP address.

From the Windows host, yes. I'm also using Linux Mint on a laptop which
uses Debian tools; the comparable command is iconfig.

Post by VanguardLH
. . .
For some reason they never divulge, or refuse to acknowledge they do not
know and are just following some canned recommendation, Comcast techs
want you to use their app instead of pushing the reset button on the
modem, or logging into the modem's internal web server.

I believe I have access to more features using the subscriber Web
interface to 10.0.0.1 on the LAN side than if I went through the Comcast
Web server on the WAN side. Although looking at the Web interface from
the LAN side, I no longer have access to port forwarding and a couple of
other features.

Reviewing the list of connected devices in the LAN, I see that I forgot
to reset two ATAs (which do SIP) and didn't reset the conference phone
(which also does SIP) which affected my 9 VoIP phone lines. It's
something I have to reset manually (by unplugging each device) after
power outages.

Post by VanguardLH
Nil and I have IMAP access, but likely we're using servers regional in
our area.

Just trying to eliminate the possibility that the Web site change with
respect to how I reach Web mail also meant something changed with
respect to IMAP or if something had happened elsewhere in the country.

Post by VanguardLH
. . . Did you check if telnetting got a response from whichever IMAP
server to which you end up connecting?

No, I haven't done that yet.

Post by VanguardLH
I don't use Comcast's DNS servers. Well, I do indirectly. IPv4 and
1.1.1.1 Cloudflare
208.67.222.222 OpenDNS
8.8.8.8 Google
10.0.0.1 cable modem
The cable modem is configured to use the upstream DHCP server (Comcast)
to get its WAN-side IP address which also means the cable modem
(10.0.0.1) will use Comcast's regional DNS server. When I do an
"nslookup imap.comcast.net" which ends up using Cloudflare's DNS server,
by default, I get a slew of IP addresses (both IPv6 and IPv4). When I
run "nslookup imap.comcast.net 10.0.0.1" (to have the router in the
cable modem simply hop the DNS lookups to the upstream server which is
whatever Comcast gave my router), I get a different list of IP
addresses. Which DNS server I end up using decides what IP addresses
get returned for the host lookup.

I'm confused. I recall when I had a separate router, I configured DNS
there, but since that became bricked, I have no way to configure DNS in
the rented cable modem, so I thought it would override any DNS
configuration I did in the host.

I'll try configuring DNS in the host to see if I can avoid Comcast's
default DNS. I don't want to use Cloudflare's.

Post by VanguardLH
. . .
If the IMAP server were down, I would expect the e-mail client to issue
a connection error (host not found). However, from your description,
looks like the IMAP server is reachable, but is not responsive, or so
overwhelmed with traffic that it is excruciatingly slow.

I just tried it again. It's still hanging. I will look up how to issue
the commands via telnet and I'll turn on logging in the client to spot
the greeting sequence.

Post by VanguardLH
If you couldn't reach the server, like it was down, I would think your
client would issue a "not found" error. If the server accepted your
connection request, but was severely slow or unresponsive, I would think
your client would eventually issue a timeout error.

It hangs for several minutes before timing out.

Post by VanguardLH
It is also possible there is such a huge message sitting in the Inbox
(or other synch'ed folder since this is IMAP) that it takes forever to
download. . . .

I don't use IMAP that way. I don't synchronize inboxes. My email client
isn't built to do that and I don't want to use a client that does. If I
save a message, I use IMAP to save it into the appropriate archived
message folder.

I'm not using this email account to receive messages with binary file
attachments. If the inbox were sent such a message, I would delete it.

I have stated repeatedly that it's just for service-related
messages. Please, there is no need to guess about anything else.

VanguardLH

2023-09-17 19:34:52 UTC

Post by Adam H. Kerman
There aren't that many email messages, perhaps a hundred. The account is
used mostly for service-related email messages.

I didn't find a FAQ article on maximum size for a message. It's not
the count of messages. It's their aggregate size. . . .

I don't want to talk about this. Your guess was wrong. For the 2,723rd
time, your guess was wrong. You aren't being helpful by making guesses.

And because you refuse to check quota usage, your guess that it is not
the culprit is also wrong. You don't know, you won't check, so you
cannot deem my guess is wrong until you check! Geez, what a onus for
you to check.

What is your fear to check quota usage, and reply if it you have plenty
left?

Post by Adam H. Kerman
It doesn't matter at this point that you didn't infer I had Web mail
access when I stated that the deep link for Web mail access had changed.

Inference is guessing interpretation. But, well, you don't want me
guessing at all, because somehow I just must know everything you do
about your e-mail setup.

Post by Adam H. Kerman
I don't know how I could have made that discovery lacking Web mail
access. In each subsequent followups, I stated that I had Web mail
access.

But you lambasted me for making the guess at the onset. You clarified
later.

Post by VanguardLH
Since you have used it, your account isn't locked out or suspended.

Nice of you to acknowledge the obvious.

Yep, hindsight is the only perfect science. Too bad you weren't clear
at the start.

Post by VanguardLH
You can also use their app to have their end send a reset to your cable
modem. A lot faster than calling them up.

See the earlier paragraph. I can now access the tool through their Web
site. I refused to install the app on my smart phone.

The app is handy when there is no Internet access. It can identify
there are outages in your area. If you have no Internet access through
the modem, and you don't want to use its reset button, or log into its
internal web server, the app lets you reset/restart your cable modem
from the outside. You may not be physical resident at the cable modem's
location when you want to reset/restart it.

I prefer to use the cable modem's reset button, or its internal web
server to reset it. Resetting doesn't re-provision the modem, though.
I doubt their web page option does, either. Easier to have the app do
the re-provision than wade through their call support prompting system,
and wait on hold for 2 hours. Re-provisioning (or setting up a new
device) is much easier using the app than calling to get them to do it.

If I can reach their web site to find a troubleshooting option to reset
my cable modem, I don't need to reset the cable modem. I already have
Internet access, and don't need to touch the modem. I don't see the
point of having the option on their web site if their door is locked.
If I can get to their web option, well, I already have Internet access.
Going to their web site to restart the modem or restart a TV box is like
asking me to go into a store to grant me access to go into the store,
but I'm already there.

Post by VanguardLH
Another way to restart the cable modem is to use a web browser to
connect to 10.0.0.1, or whatever is the IP address for the gateway.

Not during a cable outage as I have no LAN lacking a separate router.
But yes, I'm using the default IPv4 address on the LAN side.

Since you're using the cable modem's router, I don't see how your
workstation/host is not on its LAN. If the internal web server in the
cable modem is unresponsive, that's when I use its reset button. If the
web server rejects my login, I have to reset (not restart) it by holding
down the reset button longer than 10 seconds to get the modem
re-initialized to use "admin" as the user and password (and then
immediately login to change the password as the username is fixed).
It's been a long time, but I recall I've had to re-initialize (reset) to
get the internal web server working again.

Post by VanguardLH
For some reason they never divulge, or refuse to acknowledge they do not
know and are just following some canned recommendation, Comcast techs
want you to use their app instead of pushing the reset button on the
modem, or logging into the modem's internal web server.

Me, too. Whether I'm talking to a tech or using the very limited online
options at their web site, using the cable modem's web server grants me
the same options to restart or reset the modem, but lots more options
than calling or online options afford, and definitely more options than
the app affords. Those are choices are for their typical newbies that
don't how to use the modem's web server, and don't understand the
configuration options presented to them. They're dummy venues, but they
might be all you need, like a car's steering wheel devoid of cruise
control, phone, radio, and other controls.

Post by VanguardLH
Nil and I have IMAP access, but likely we're using servers regional in
our area.

Post by VanguardLH
. . . Did you check if telnetting got a response from whichever IMAP
server to which you end up connecting?

No, I haven't done that yet.

Until you enable logging in your e-mail client (and assuming it includes
showing the intial handshaking which means you may have to go into
detail level in the log), you don't know if the IMAP server (or your
client) is hanging on the handshaking to establish a session, or on a
client-issued command during the mail session.

Rather than delve into a logfile which probably has to be configured to
show full details (debug mode), might be easier to view an error
console. My client has one, I recall Outlook has one, but it's been
over 3 years since I used Thunderbird. If using Tbird, I think you can
use menu -> Tools -> Developer Tools -> Error Console, or hit
Ctrl+Shift+J. You might see something there before having to decipher a
logfile. In the Error Console, you can decide how much to see: Errors,
Warnings, Logs, Info, and Debug. It probably looks akin to:

Loading Image...

If using something else as your e-mail client, you'll need to see if it
has an error console that is a bit simpler to decipher than to create a
logfile. Or you might be stuck creating a logfile, but may have to up
its detail level to determine at which point the client is hanging.

Actually the host will pass DNS requests to the upstream DNS server. If
you configure IPv4 and IPv6 in the host OS as to which DNS servers it
should use, it'll use those before falling (failing) down through each
alternative DNS server. The last DNS server in my config is for the
cable modem that gets its DNS server assigned from the upstream DHCP
host is is my ISP's DHCP server. So, if my host cannot reach the
Cloudflare, OpenDNS, or Google DNS servers then it falls down to the
cable modem's DNS server which really doesn't have one and merely passes
the DNS requests to its upstream DNS server (at my ISP).

In prior leased cable modems from Comcast, there was a DNS setting in
the modem's internal web server settings. In the cable modem I'm now
leasing from Comcast, nope, that setting is gone. So are many other
settings that I used to have. They've dummied down the modem's config.
That means the modem is going to get the DNS server specified by its
upstream DHCP server, and that's the ISP's DHCP server. The ISP's DHCP
server is going to assign whatever DNS server is defined for that region
by the ISP. That's why I eventually fallback in my OS' DNS config to
the cable modem which then will simply pass DNS requests up to my ISP's
DNS server for the region they assign to me.

However, in the DNS config in the OS (for IPv4 and IPv6), the OS will
first use those specified DNS servers in the order specified for
fallback order. In Windows, I use ncpa.cpl to view the connectoids,
right-click on the active one to select Properties, and double-click on
"Internet Protocol Version (TCP/IPv4)" (and later do the same for IPv6)
to look at that interface's properties. Under the General tab, I click
on Advanced, and select the DNS tab. I think you can add up to 10 DNS
servers (by IP address), but I only have 4 defined: Cloudflare, OpenDNS,
Google, and the cable modem. If DNS is so fucked that no DNS server can
be reached within a list of 4, one of which is the cable modem, then I
have some really nasty problem at the workstation/intranet host.

I haven't use *NIX for a long time, and each has their own variation on
how to configure DNS lookups.

Note that Windows has a DNS Cache Client service. Old DNS requests get
cached for a while whether the DNS lookup was successful or failed.
Rather than get into what registry settings you can change on how long
to retain successful lookup, and what to configure for retention of
failed lookups, and I don't recommend disabling the DNS Client in
Windows services (services.msc), if I change the DNS setup then I clear
the DNS cache by running:

ipconfig /flushdns

That cleans out the local DNS cache, and subsequent lookups will add new
entries. It is possible, for example, that a failed lookup is still in
the cache, so subsequent lookups will also fail because they first come
from the cache. Even if the DNS server comes back up or becomes
reachable again, the lookup will again fail until the expiration of
failed entries in the DNS cache. Entries get removed from the cache
after the TTL (Time To Live) expires on an entry. Usually success
lookups live longer than failed lookups. That way, DNS lookups are much
faster from the local cache for sites you've already visited, but later
revisit.

You'd think a single DNS lookup from cache or query to a DNS server
wouldn't be much different in how you experience the Web. True *if* the
site does not refer anywhere else. Nowadays, sites get their content
from multiple other sites, like CDNs (Content Delivery Networks). Even
Microsoft uses Akamai for many of their downloads. For every resource
within a web page that references another domain, another DNS lookup is
required. Even for on-domain resources, IP addresses are rarely used,
and instead hostnames are used, and each requires a DNS lookup. A web
page could have hundreds or thousands of resources, and each one using a
FQDN requires yet another DNS lookup. Having a local DNS cache speeds
up all those DNS lookups by returning entries from the cache instead of
having to pass more traffic to the Internet, get past your provider's
network, make hops to get to the target DNS server, have the server do
the lookup, and send the traffic all the way back to your host before
your host gets the IP address to find the resource.

In Windows, I had to figure out how to delve through their wizards to
find the DNS server config. In Linux, you probably have to delve into
config files for that OS' DNS config, like /etc/resolv.conf. For
example, see:

https://unix.stackexchange.com/questions/494324/how-to-setup-dns-manually-on-linux

I would assume if you never configure the OS' DNS config that the
default is to use whatever the upstream DHCP server assigned to your OS.
In your case, the upstream DHCP server is in the cable modem. However,
if there is no DNS config in the modem, it gets its DNS server from its
upstream DHCP server which is at your ISP (Comcast). Consumer modems
don't actually have a DNS server. They just pass on the DNS requests to
the DNS server they've been configured to use (whether configured by you
in the modem's settings, or by its upstream DHCP server).

Even DNS servers have their own caching trying to speed up their
response time for the most looked-up targets. GRC's DNS Benchmark tool
(https://www.grc.com/dns/benchmark.htm) will show you which DNS servers
employ their own caching, benchmark different DNS servers (to your
host), and even show you which ones will rudely redirect you to their
"helper" web page instead of returning a failed lookup (and the helper
page takes time to reload, and can screw up clients that handle failed
lookups, not successful lookups but resulting in a redirect to a helper
page).

There's still another possible problem source: server farms. Even if
you and I used the same IP address for the IMAP server, they likely
operate a front-end server that decides which IMAP server in their
server farm that will handle the mail session. They want to load
balance the workload across multiple servers. It's up to them what
algorithms their front-end server uses to decide which target IMAP
server actually handles your session. They may, for example, decide
which IMAP server their front-end server sends you based on the
geolocation of your IP address.

I had a web site (Creative Labs) that was not reachable when
connecting to them from home. I usedopen proxies to come at them from
different regions mostly to check if a particular hop in my route to
them was down or very slow. What I found was that I could get at them
from the East coast and West coast routes, but not a route from my
midwestern location. I contacted Creative, and worked with their tech
to determine which routes worked, and what was my route. Turned out
their front-end server was redirected my midwest connect to a web
server in their farm that was down. Got a free USB flash drive for
helping them discover a dead backend web server in their farm.

So, you might try using an open proxy or a VPN to come at Comcast's IMAP
server from a different location giving you a different route to them.
You're not trying to lie about your geolocation for your IP address
since they will still get that using an open proxy (but not with a VPN),
but more about you trying to use a different route to see if the farming
algorithm gets you to a different backend (internal) IMAP server.

It hangs for several minutes before timing out.

Many years ago, the typical or default timeout was about 5 minutes.
Could be client dependent, and perhaps even user configurable. That was
because servers could get highly overloaded, they accept but pend the
connection request, but take so long to get back to the request that the
client times out.

Do you run anti-virus software that interrogates your e-mail traffic?
If so, that is superfluous protection. The same on-demand (real-time)
AV scanner is used to interrogate your e-mail traffic. When you attempt
to extract an attachment in an e-mail, the on-demand scanner gets used
when the new file is created. So, you get no additional coverage. The
only advantage to e-mail scanning is when a pest is discovered: when the
e-mail was delivered, or when an attachment got extracted. However, all
e-mail is sent as plain (ASCII) text, even binary attachments in MIME
parts that are long text encoded strings (at about 1.5, or more, times
the number of bytes as the original binary file). Malware as text
sitting in an e-mail is harmless. Only when you extract it (convert
from long encoded text string back into an executable file) is the
malware a potential threat. AV scanning of e-mail can cause timeouts
due to its proxy interrogating that traffic stream. Try temporarily
disabling the e-mail scan option in your AV software. Personally I'd
just leave it disabled permanently. Same if the AV also interrogates
your newsgroups traffic.

Post by VanguardLH
It is also possible there is such a huge message sitting in the Inbox
(or other synch'ed folder since this is IMAP) that it takes forever to
download. . . .

Which still means IMAP is used to download the message. E-mail servers
are not fast, like file servers. Messages takes a lot longer to
download from mail servers than downloading from file servers (however,
some file servers will also throttle the connection to slow the transfer
since they have limited hardware to handle all download requests).

You're still using IMAP to retrieve the message, and a huge message will
take a long time to retrieve over the throttled e-mail session. You
still need someway to know you have a new message to download, but I
don't know how you achieve that without synchronization. Maybe your
client just gets the overview headers, so you know what messages are
available on the server. And then you pick which message(s) to
retrieve. Okay, but whether synchronized or manual retrieval, you're
still using IMAP in a mail session to get the message.

Did you check using the webmail client if you have any huge messages?
If not synchronizing, but doing manual retrieves, do you still get the
hang in the mail session when you try to re-retrieve a small message
you've already retrieved before? That is, does the hang occur when you
attempt to [re]retrieve messages you know are small, like 5 KB?

Post by Adam H. Kerman
I'm not using this email account to receive messages with binary file
attachments. If the inbox were sent such a message, I would delete it.
I have stated repeatedly that it's just for service-related
messages. Please, there is no need to guess about anything else.

Sorry, "service-related messages" does not mandated the messages are
small. They could have logfiles or screenshots. Guessing (assumption)
is needed until clarification is provided. So, now I know the messages
in your Comcast account are small, like perhaps under 15 KB in size, or
even smaller.

Adam H. Kerman

2023-09-17 20:00:40 UTC

Post by Adam H. Kerman
There aren't that many email messages, perhaps a hundred. The account is
used mostly for service-related email messages.

I didn't find a FAQ article on maximum size for a message. It's not
the count of messages. It's their aggregate size. . . .

I don't want to talk about this. Your guess was wrong. For the 2,723rd
time, your guess was wrong. You aren't being helpful by making guesses.

I already know because the account is not shut down.

Post by VanguardLH
What is your fear to check quota usage, and reply if it you have plenty
left?

Of course your unwillingness to read what I have written for meaning is
my fault.

You get the last 5000 words here, VanguardLH. I'm not reading any more.
It's impossible for two people to have a conversation when one doesn't
listen.

VanguardLH

2023-09-17 20:44:46 UTC

Post by Adam H. Kerman
There aren't that many email messages, perhaps a hundred. The account is
used mostly for service-related email messages.

I didn't find a FAQ article on maximum size for a message. It's not
the count of messages. It's their aggregate size. . . .

I don't want to talk about this. Your guess was wrong. For the 2,723rd
time, your guess was wrong. You aren't being helpful by making guesses.

I already know because the account is not shut down.

Post by VanguardLH
What is your fear to check quota usage, and reply if it you have plenty
left?

Of course your unwillingness to read what I have written for meaning is
my fault.
You get the last 5000 words here, VanguardLH. I'm not reading any more.
It's impossible for two people to have a conversation when one doesn't
listen.

Then you deliberately choose not to see other possibly helpful info.
Well, hope all those suggestions in the plethora of other responses
gives you a solution. <wink wink>

VanguardLH

2023-09-17 20:12:05 UTC

Post by Adam H. Kerman
I have stated repeatedly that it's just for service-related
messages. Please, there is no need to guess about anything else.

Say you tell me to send you a log file. It is 21.5 MB in size (yep,
it's a text file, but it is still a huge log file, and I've got one that
size at C:\Windows\Panther\Rollback\FolderMoveLog.txt). I could
compress it down to an 887 KB .zip file, and attach to my e-mail to you.
But you refuse any e-mails with attachments, so I have to copy the 21.5
MB of text into the body of my e-mail. Along with my explanation of the
problem, directions on how to reproduce, and other contextual
information, that e-mail could be about 22 MB in size, and it's all text
with no attachments. Whether or not you receive it depends on quotas
for your e-mail account, like how large can be messages. If 22 MB was
acceptable to your e-mail provider, and because e-mail servers are
throttled (you don't get the speed of your broadband connection, but
something far less), it can take a while before your client completes
the download of that message. However, along comes the next mail poll
by your client (by you manually or sync poll) which aborts the download,
and it starts over again in the next mail poll, and repeats ad nauseum.
With manual polls, and if you wait indefinitely for a message retrieval
that may never complete, you don't run into restarting the mail session
that then tries to redownload the same huge file.

Saying the messages are service-related says nothing regarding their
size. For most everyday e-mailed discussions with no attachments and
all text (no HTML or inline resources), 80 KB is rather large, and 5 KB
typical of memos. For technical communications that may involve
transferring log files, even if all text, the messages could be huge.
"Service-related" does not equate to tiny. Sorry, "service-related"
really doesn't give detail, like size.

Without guessing at all, the size of the message mandates how long to
download, and the mail polling interval mandates how long the download
can last. If all the "service-related" messages, whatever they may be,
are somewhere around 5 to 50 KB in size then message size is not a
likely cause. However, message corruption can still be an issue. If
the message is corrupted on the mail server, the mail program may puke
on delivering that message. I remember back when ISPs gave you a shell
where I could run 'mail' or 'pine' to troubleshoot my e-mail service,
especially to get rid of a corrupted message on which the mail server
would hang during delivery. Nope, no shells anymore. You have to get
rid of the problematic message that interferes with message retrieval,
and move on to retrieving the other messages.

When manually retrieving e-mail (since you don't allow synchronization
in the client), are you selecting just 1 message to retrieve, or a bunch
of them? If selecting just 1, and there is a hang, could be that's the
problematic message the server has trouble delivering. Try another
different message, like one already retrieved successfully, to test if
the hang occurs even on "good" messages. If selecting multiple messages
for a manual poll, especially the same one in the set, try doing one at
a time.

Char Jackson

2023-09-19 01:37:49 UTC

Post by VanguardLH
It is also possible there is such a huge message sitting in the Inbox
(or other synch'ed folder since this is IMAP) that it takes forever to
download. E-mail servers are nowhere near as fast as file server, plus
each connection is deliberately throttled, so all concurrent users get
some performance.

Not saying you're wrong about the throttling claim, but I've seen a few hundred
enterprise email servers over the past 6-8 years and I've never seen one that
was throttled in any way. Email admins want those sessions to complete as
quickly as possible to free up resources for the next client that comes along.
Throttling would artificially extend each session, which would have no benefit.

VanguardLH

2023-09-19 05:58:36 UTC

Post by Char Jackson

Send yourself a huge test e-mail (that is under any per-message quota of
your e-mail provider), and see how long it takes to download. Measure
your bandwidth. Then do a manual retrieve of just the one test message.
Compare the download speed to get the message compared to the bandwidth
at your end.

Comcast has a max storage quota of 10 GB for e-mail accounts. Max size
for a message is 25 MB. That doesn't seem large enough with broadband
traffic to accurately measure the time for a message download compare
to, say, if you were transferring a file at the full downstream
bandwidth you get from your ISP. If your e-mail client's logging
include timestamps down to the millisecond, maybe you can see how long
to retrieve the message to see if it took as long, or longer, than your
Internet connection. I don't know how accurate are the timestamps in
logs of e-mail clients, or if granular enough to measure the time to
transfer a message (timestamps at 1-second intervals would be far too
coarse a measure).

Using https://speedtest.xfinity.com/, my downstream speed is 508 Mbps.
Without throttling at the e-mail server (I'd get all my bandwidth used
for an IMAP connection), a 25 MB message (200 Mb), and discarding extra
bytes for packet structure for the network traffic, that message would
take 2.54 seconds to retrieve. I really doubt I'd get a 25 MB e-mail
from their IMAP server in 2.54 seconds. Huge e-mails always seem to
take a while to get, and stall getting other messages.

Even if there is no bandwidth throttling on mail sessions at the server,
note there are MANY concurrent mail sessions at the server. Lots of
users will be trying to get or send e-mails at the same time. The
server's bandwidth has to get shared across all current connections.
Sharing of bandwidth is itself throttling. You don't get the full
attention of the server. You get a slice. Due to parallelized
processes, you also don't get to dedicate the entire bandwidth at the
mail server to your retrieve, but just get a slice. Many mail sessions.
Many network streams. I doubt any mail server handles only 1 mail
session at a time and dedicates its entire bandwidth for that 1 mail
session.

Char Jackson

2023-09-20 03:20:38 UTC

Post by Char Jackson

But that's not throttling. That's just the reality that mail servers aren't as
fast as file servers. Different protocols, different payloads, different server
architectures, etc. To me, throttling implies that an artificial limit has been
imposed on the session, especially the transport aspect of the session, and I
don't think I've ever seen that.

Post by VanguardLH
Comcast has a max storage quota of 10 GB for e-mail accounts. Max size
for a message is 25 MB. That doesn't seem large enough with broadband
traffic to accurately measure the time for a message download compare
to, say, if you were transferring a file at the full downstream
bandwidth you get from your ISP. If your e-mail client's logging
include timestamps down to the millisecond, maybe you can see how long
to retrieve the message to see if it took as long, or longer, than your
Internet connection. I don't know how accurate are the timestamps in
logs of e-mail clients, or if granular enough to measure the time to
transfer a message (timestamps at 1-second intervals would be far too
coarse a measure).

You're talking about what you may be seeing from an end user perspective, and I
could do the same, but I work in the enterprise networking space, very
frequently interfacing directly with the email admin teams. I've never seen any
throttling there, and in fact, they always ask what we could do to make things
faster. My answer is usually simple: add more mail servers to the load balanced
server pool.

That reminds me, the "front end server" that you mentioned in a previous post is
99.9% of the time a dedicated network appliance known as a load balancer, versus
some kind of general purpose computer that just happens to do load balancing.

Post by VanguardLH
Using https://speedtest.xfinity.com/, my downstream speed is 508 Mbps.
Without throttling at the e-mail server (I'd get all my bandwidth used
for an IMAP connection), a 25 MB message (200 Mb), and discarding extra
bytes for packet structure for the network traffic, that message would
take 2.54 seconds to retrieve. I really doubt I'd get a 25 MB e-mail
from their IMAP server in 2.54 seconds. Huge e-mails always seem to
take a while to get, and stall getting other messages.

It looks like you're assuming throttling because you're not seeing the
throughput that you'd like to see. I feel pretty safe in saying that that would
be an incorrect assumption.

Post by VanguardLH
Even if there is no bandwidth throttling on mail sessions at the server,
note there are MANY concurrent mail sessions at the server. Lots of
users will be trying to get or send e-mails at the same time.

Of course. The busiest times for enterprise email systems are early in the day,
as employees are arriving for work, immediately before and after the lunch
period, and the last hour or so before the workday ends. For a consumer facing
ISP like Comcast, the busy hours won't be so well defined, but the mail servers
are never sitting idle, I think it's safe to say.

Post by VanguardLH
The
server's bandwidth has to get shared across all current connections.
Sharing of bandwidth is itself throttling.

That's not what I expected you to mean when say there's throttling. That's just
bandwidth being shared.

Post by VanguardLH
You don't get the full
attention of the server. You get a slice. Due to parallelized
processes, you also don't get to dedicate the entire bandwidth at the
mail server to your retrieve, but just get a slice. Many mail sessions.
Many network streams. I doubt any mail server handles only 1 mail
session at a time and dedicates its entire bandwidth for that 1 mail
session.

You're telling me about my work. I'm very well aware. ;-)

Allodoxaphobia

2023-09-17 17:58:39 UTC

Post by Adam H. Kerman
Yesterday, Comcast changed to Web site path to check email. The deep
link is now https://connect.xfinity.com/appsuite/ although the previous
deep link redirects.
I haven't been able to access my inbox via IMAP. I don't even get the
"temporarily blacklisted" error message; the client just hangs. I looked
at the setting page; settings have not changed. I did change from the
Comcast ID to the email address as username in case that made a
difference, but it didn't.
Was anyone able to access Comcast email yesterday or today via IMAP?

For some time now (maybe a year?) I have experienced 'hangs' about 70%
of the time when I try to fetch email from Comcast imap servers (from
near Pueblo, Colo.)

What I've done is create a script to run in the background that attempts
to fetch mail from their server(s). If the fetch times out, a delay for a
minute is set, and the attempt is tried again. It runs in the
background and can't really annoy me, and since Comcast is *not* my
primary email gateway, I really don't give a crap. :-)

Example from a log I keep. The date/time is written before
each attempt:

|Sat Sep 16 05:05:42 MDT 2023
|fetchmail: terminated with signal 15 <<== FAIL
|Sat Sep 16 05:06:50 MDT 2023
|fetchmail: terminated with signal 15 <<== FAIL
|Sat Sep 16 05:07:58 MDT 2023
|fetchmail: No mail for example.net at imap.comcast.net <<== SUCCESS

I believe it depends on which way you hold your tongue and which of
the comcrap servers you get connected to.
........... Well, that just one of my guesses on the problem.

Jonesy

Adam H. Kerman

2023-09-17 18:20:07 UTC

Post by Allodoxaphobia

. . .

For some time now (maybe a year?) I have experienced 'hangs' about 70%
of the time when I try to fetch email from Comcast imap servers (from
near Pueblo, Colo.)
What I've done is create a script to run in the background that attempts
to fetch mail from their server(s). If the fetch times out, a delay for a
minute is set, and the attempt is tried again. It runs in the
background and can't really annoy me, and since Comcast is *not* my
primary email gateway, I really don't give a crap. :-)
Example from a log I keep. The date/time is written before
|Sat Sep 16 05:05:42 MDT 2023
|fetchmail: terminated with signal 15 <<== FAIL
|Sat Sep 16 05:06:50 MDT 2023
|fetchmail: terminated with signal 15 <<== FAIL
|Sat Sep 16 05:07:58 MDT 2023
|fetchmail: No mail for example.net at imap.comcast.net <<== SUCCESS

Yes, that's the right thing to do. Even the guy who maintains the email
client I use says he DOES NOT use his own client to check inboxes on
foreign networks but does it entirely as a independent process.

Post by Allodoxaphobia
I believe it depends on which way you hold your tongue and which of
the comcrap servers you get connected to.
........... Well, that just one of my guesses on the problem.

Hahahahahahaha

How did you rule out sunspots?

Dyslexic

2023-09-18 09:50:20 UTC