"Adam H. Kerman" <ahk@chinet.com> wrote:

> VanguardLH <V@nguard.LH> wrote:
>>"Adam H. Kerman" <ahk@chinet.com> wrote:
>
>>>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?

> 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.

> 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.

>>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.

>>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.

>>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.

>>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.

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.

>>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.
>
>>. . . 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:

https://assets-prod.sumo.prod.webservices.mozgcp.net/media/uploads/images/2016-07-16-21-54-24-0d6e04.png

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.

>>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'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.

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.

>>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.

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.

>>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.

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?

> 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.