The IP address from which I use IMAP to check email (which is NOT on my
home network, shut up Vanguard) has been "temporarily blacklisted" for a
month now.

Can I conclude it's been permanently blacklisted yet?

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

> The IP address from which I use IMAP to check email (which is NOT on
> my home network, shut up Vanguard) has been "temporarily blacklisted"
> for a month now. ^^^^^^^^^^^^^^^^
\___ I don't do requests.
(https://www.youtube.com/watch?v=13nFUAzv-Hs)

> Can I conclude it's been permanently blacklisted yet?

Other than Comcast's own blacklist, have you checked if your IP address
from wherever has been blacklisted elsewhere?

https://mxtoolbox.com/blacklists.aspx

Is it a dynamic or static IP address? Odd Comcast would block when
reading (IMAP) versus from sending (SMTP). That IP address can only
read, and never sends? If sends come from that IP address, perhaps you
can check the outgoing mail volume from it. Comcast has their
anti-abuse quotas on sending for personal-use service tiers, like a max
of 100 recipients per message, an aggregate total of 1000 recipients per
day across all sent messages, a message must be under 25 MB in size (and
that includes the bloat of encoding binary attachments into long text
strings). You need a business-use account to exceed those quotas. They
don't allow sending attachments of some filetypes (vbs, pif, scr, bat,
com, cmd, msi, reg, and exe), so you have to pack those into a .zip file
to attach to your message. If that IP only reads (IMAP), your e-mail
client won't show you the authentication or read errors?

https://www.xfinity.com/support/articles/determine-blocked-ip-address
which links to an article on the BLxxxxxx error codes at:
https://www.xfinity.com/support/articles/email-errors

I suspect those errors involve sending, not reading. However, if the IP
address has been blacklisted, Comcast might disable all connects to it.

No one at Comcast can help, or understand your oddball setup?

Um, this isn't an error to authenticate to Comcast, is it? You do know
they got hacked a few months ago, and since the data breach on 36
million accounts then required their users to change their passwords.
Not sure when was the breach, but Comcast disclosed on Dec 18. The
password change wasn't required immediately. I think I had to change my
password about a month ago, but I procrastinated for a while since they
are a low secondary e-mail provider, not my primary e-mail provider.

VanguardLH <V@nguard.LH> wrote:
>"Adam H. Kerman" <ahk@chinet.com> wrote:

>>The IP address from which I use IMAP to check email (which is NOT on
>>my home network, shut up Vanguard) has been "temporarily blacklisted"
>>for a month now. ^^^^^^^^^^^^^^^^
> \___ I don't do requests.
> (https://www.youtube.com/watch?v=13nFUAzv-Hs)

>>Can I conclude it's been permanently blacklisted yet?

>Other than Comcast's own blacklist, have you checked if your IP address
>from wherever has been blacklisted elsewhere?

>https://mxtoolbox.com/blacklists.aspx

It's not blacklisted on any third-party blacklist, and it's not blacklisted
specifically by Comcast. Comcast is blacklisting the entire /24.

Comcast doesn't like the quantity -- without making a spam determination
-- of messages its subscribers are receiving from one or more IP
addresses during a given period of time, so the entire /24 gets blocked.

>Is it a dynamic or static IP address?

Again. I check email from a host on another network. I don't check email
from my home network. DHCP is irrelevant.

>Odd Comcast would block when reading (IMAP) versus from sending (SMTP).

I cannot speculate why IMAP is blocked, but Comcast linked it to the
"problem" it's trying to address. It simply refuses to connect for any
purpose.

I'm massively snipping guesses that have nothing to do with this.

>https://www.xfinity.com/support/articles/determine-blocked-ip-address
>which links to an article on the BLxxxxxx error codes at:
>https://www.xfinity.com/support/articles/email-errors

Yes, I've long had those pages bookmarked. They aren't specific to the
issue at hand.

>I suspect those errors involve sending, not reading. However, if the IP
>address has been blacklisted, Comcast might disable all connects to it.

No shit. But it's nothing to do with what I am sending nor the tiny
amount of outbound email messages originating at that IP address. When
using the Comcast email address, SMTP uses the required credentials with
the required Comcast Mail server.

>No one at Comcast can help, or understand your oddball setup?

I have no idea how you determined that there's anything "oddball setup"
about using IMAP. Please explain.

>Um, this isn't an error to authenticate to Comcast, is it?

No. I do remember to save the changed password.

>. . .

On Mon, 25 Mar 2024 16:10:41 -0000 (UTC), Adam H. Kerman wrote:
>
> It's not blacklisted on any third-party blacklist, and it's not
> blacklisted specifically by Comcast. Comcast is blacklisting the
> entire /24.

Then they may be blocking by domain assignment. Once bad actors appear
from some domain, it's generally simpler to block by /24 than by /32 --
unless the whole domain is deemed full of bad actors -- where you'd
block by the whois range.

Jonesy

Allodoxaphobia <trepidation@example.net> wrote:
>On Mon, 25 Mar 2024 16:10:41 -0000 (UTC), Adam H. Kerman wrote:

>>It's not blacklisted on any third-party blacklist, and it's not
>>blacklisted specifically by Comcast. Comcast is blacklisting the
>>entire /24.

>Then they may be blocking by domain assignment. Once bad actors appear
>from some domain, it's generally simpler to block by /24 than by /32 --
>unless the whole domain is deemed full of bad actors -- where you'd
>block by the whois range.

The network in question has a number of domains but just two IP address
in different /24s. The host I log into got moved from one IP to the
other recently. Each time they install a new host, it gets put on the
other IP for obvious reasons. Both IP addresses have been "temporarily
blocked" but this one has been blocked for a month.

The hosts are virtual and live on a server farm, so there are many many
accounts and domains within the two affected /24s.

I'm sure you are right that the entire /24 gets onto Comcast's blacklist
for some bad actor whose account likely got take down in short order.

On 3/25/24 02:32 PM, Adam H. Kerman wrote:
> Allodoxaphobia <trepidation@example.net> wrote:
>> On Mon, 25 Mar 2024 16:10:41 -0000 (UTC), Adam H. Kerman wrote:
>
>>> It's not blacklisted on any third-party blacklist, and it's not
>>> blacklisted specifically by Comcast. Comcast is blacklisting the
>>> entire /24.
>
>> Then they may be blocking by domain assignment. Once bad actors appear
>>from some domain, it's generally simpler to block by /24 than by /32 --
>> unless the whole domain is deemed full of bad actors -- where you'd
>> block by the whois range.
>
> The network in question has a number of domains but just two IP address
> in different /24s. The host I log into got moved from one IP to the
> other recently. Each time they install a new host, it gets put on the
> other IP for obvious reasons. Both IP addresses have been "temporarily
> blocked" but this one has been blocked for a month.
>
> The hosts are virtual and live on a server farm, so there are many many
> accounts and domains within the two affected /24s.
>
> I'm sure you are right that the entire /24 gets onto Comcast's blacklist
> for some bad actor whose account likely got take down in short order.
What is 24/s? I've seen this before but never looked it up.
--
Linux Mint 21.3 Cinnamon 6.0.4 Kernel 6.5.0-26-generic
Al

Big Al <alan@invalid.com> wrote:

>>. . .

>What is 24/s? I've seen this before but never looked it up.

CIDR notation

Three decades ago, routing went "classless", dropping the fixed 8-bit
groups. It's an easy way to make the calculation of how many IP
addresses are available for assignment here.

The Wiki page has a decent explanation.

https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation

On 3/25/24 03:17 PM, Adam H. Kerman wrote:
> Big Al <alan@invalid.com> wrote:
>
>>> . . .
>
>> What is 24/s? I've seen this before but never looked it up.
>
> CIDR notation
>
> Three decades ago, routing went "classless", dropping the fixed 8-bit
> groups. It's an easy way to make the calculation of how many IP
> addresses are available for assignment here.
>
> The Wiki page has a decent explanation.
>
> https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation
Thanks. You can teach an ole dog new tricks. 😀
--
Linux Mint 21.3 Cinnamon 6.0.4 Kernel 6.5.0-26-generic
Al

I filled out the form and received a generic reply that failed to
address the situation, but promising to block the IP again if spam
is once again detected, not having detected any from the host I use in
the first place.

The Comcast address isn't used for any mission-critical email, just service
related email from Comcast and a few specific utilities.

It would be a bad idea to rely upon the Comcast address for anything. If
you're out of town, then you'll be using IMAP from a network Comcast
doesn't recognize and possibly subject to the temporary blacklist.

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

> VanguardLH <V@nguard.LH> wrote:
>
>> Is it a dynamic or static IP address?
>
> Again. I check email from a host on another network. I don't check email
> from my home network. DHCP is irrelevant.

The other network will still have an IP address. I've seen where an
e-mail provider won't accept beyond a threshold of e-mail from a dynamic
IP address, but will accept lots more from a static IP address. I said
"it" to be from WHEREVER you are connecting to their server. "It" could
be from your home network, from another off-network host, from another
e-mail provider's poll feature, or wherever, but "it" will still have an
IP address.

>>Odd Comcast would block when reading (IMAP) versus from sending (SMTP).
>
> I cannot speculate why IMAP is blocked, but Comcast linked it to the
> "problem" it's trying to address. It simply refuses to connect for any
> purpose.

Do you get an error when you attempt to telnet to their server just to
connect (not to send any IMAP commands)?

>>No one at Comcast can help, or understand your oddball setup?
>
> I have no idea how you determined that there's anything "oddball setup"
> about using IMAP. Please explain.

You aren't polling from a client in your network as a Comcast customer.
You are polling from somewhere other than the IP address they attribute
to your account with them.

With another e-mail provider (e.g., Hotmail, Gmail), can you use their
mail poll feature to get emails via IMAP from your Comcast account?
That would test if Comcast allows IMAP access from non-customer IPs.

Oh, deeper in the subthread, in your reply to Allo, you say your IMAP
client is at some hosting provider. In that case, it isn't you
connecting to Comcast's IMAP server, but your virtual host at the
hosting provider. Don't see complaining to Comcast is going to help
since they're blocking your hosting provider, not you. Likely you need
to report the issue to your hosting provider, so they can contact
Comcast to get de-listed. You need to get your hosting provider and
Comcast to cooperate on a resolution, but probably after your hosting
provider nails the bad actor (first clean up their own filth) before
wasting Comcast's time.

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

> I filled out the form and received a generic reply that failed to
> address the situation, but promising to block the IP again if spam
> is once again detected, not having detected any from the host I use in
> the first place.
>
> The Comcast address isn't used for any mission-critical email, just service
> related email from Comcast and a few specific utilities.
>
> It would be a bad idea to rely upon the Comcast address for anything. If
> you're out of town, then you'll be using IMAP from a network Comcast
> doesn't recognize and possibly subject to the temporary blacklist.

I ran into the opposite situation: Comcast let me rescue my other
accounts. I have a Hotmail account whose recovery e-mail address was my
Gmail address. In my Gmail account, my Hotmail account was the recovery
e-mail address. When I travelled to vacation, both saw I was in a
different region, and required sending me a recovery e-mail. Hotmail
would send to Gmail, but I couldn't log into Gmail. Gmail would send to
Hotmail, but I couldn't log into Hotmail. Each wanted to do a recovery
e-mail to the other account, so I was locked out of both. I then
switched both Hotmail and Gmail to use my Comcast account as the
recovery e-mail address. Comcast doesn't enforce the regional lockout.
Alas, I could change the recovery e-mail address in my Hotmail and Gmail
accounts until I got back home.

Comcast is definitely not my primary e-mail provider, but I do use it as
a secondary account. For example, Hotmail and Gmail have both refused
(and changed what they refuse) in the username token of an e-mail when
sending e-mails. I use an anonymizing e-mail service (was Spamgourment,
changed to Anonaddy) that incorporates token within the username used
when replying to determine the recipient's e-mail address. As I recall,
a pound symbol (#) was used in the username field. When I tried to
reply to the aliased e-mail, Hotmail would bitch that I specified an
invalid username (which is not true as # is an allowable character), and
so did Gmail. At times both would relax their username syntax rules,
but then reinstate them. So getting - and replying - to aliased e-mails
sent to my Hotmail or Gmail account was unreliable. I'd get the aliased
e-mails, but could not reply. Comcast didn't use such brain-dead
parsers, and would accept # in username, so I designated my Comcast
account to receive the aliased e-mails (so I could reply to them, if
needed).

Personally I don't recommend relying on your ISP's e-mail service as
your primary e-mail source. If you change to a different ISP (with the
same locality, or you move), you lose the old e-mail address. Before
you lose it, you need to change to your new e-mail address. Many sites,
when trying to change your login, want to send a confirmation e-mail to
your configured (old) e-mail address. If you don't have it anymore, you
can't get the confirmation e-mail to update your account to reflect your
new e-mail address. Using an e-mail service independent of your ISP
means you keep the same e-mail address regardless of changing ISPs, or
them going out of business or getting acquired to eventually lose the
old domain. My local ISP carried newsgroups. They got acquired, and
the new company continued newsgroups. Comcast acquired them. About 2
years later Comcast dropped newsgroups. They could also drop e-mail
service, or move it to a pay-tier service. A lot of customers would
complain, but e-mail is not an essential service to an ISP. It's
considered a perk that generates no revenue (except maybe for paid
business-use service tiers). Many users consider e-mail at their ISP to
be too big to fail, until it happens.

VanguardLH <V@nguard.LH> wrote:
>"Adam H. Kerman" <ahk@chinet.com> wrote:
>>VanguardLH <V@nguard.LH> wrote:

>>>Is it a dynamic or static IP address?

>>Again. I check email from a host on another network. I don't check email
>>from my home network. DHCP is irrelevant.

>The other network will . . .

Do you ever drop anything? DHCP is not in use. It is not a factor. DHCP
is irrelevant.

>>>Odd Comcast would block when reading (IMAP) versus from sending (SMTP).

>>I cannot speculate why IMAP is blocked, but Comcast linked it to the
>>"problem" it's trying to address. It simply refuses to connect for any
>>purpose.

>Do you get an error when you attempt to telnet to their server just to
>connect (not to send any IMAP commands)?

Hm. I never thought to try.

telnet imap.comcast.net 993

Ok. I tried it with the Comcast ID username and with the email address
as well, and escaping the @. It just hangs. I don't get a response. No
prompt for a password.

>>>No one at Comcast can help, or understand your oddball setup?

>>I have no idea how you determined that there's anything "oddball setup"
>>about using IMAP. Please explain.

>You aren't polling from a client in your network as a Comcast customer.
>You are polling from somewhere other than the IP address they attribute
>to your account with them.

This would be how one would reach the inbox when travelling. The
protocol does not anticipate that the user is on any particular network.

>Oh, deeper in the subthread, in your reply to Allo, you say your IMAP
>client is at some hosting provider. In that case, it isn't you
>connecting to Comcast's IMAP server, but your virtual host at the
>hosting provider.

I am aware of what network the IP address is in.

>Don't see complaining to Comcast is going to help since they're
>blocking your hosting provider, not you.

You really do have your fingers in your ears whenever I make statements.
The IP address isn't blocked. The domain isn't blocked. The block is
upon the two /24s their two IP addresses are in. I had the same chronic
problem when the host was on the other IP address.

>Likely you need
>to report the issue to your hosting provider, so they can contact
>Comcast to get de-listed. You need to get your hosting provider and
>Comcast to cooperate on a resolution, but probably after your hosting
>provider nails the bad actor (first clean up their own filth) before
>wasting Comcast's time.

Very little email originates at this host and there are no spammers
on the host. You asked me before if it was blacklisted at any of the
major third-party lists for being a spam source. It is not. I keep
repeating myself.

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

> Do you ever drop anything? DHCP is not in use. It is not a factor. DHCP
> is irrelevant.

So, all that noise insinuates that your IP address of your IMAP client
(*wherever* it is) a static IP address. However, doesn't seem you get
to decide its value. It is a static IP address assigned to your hosted
client by the hosting provider (and not any IP assigned by them to your
IMAP client).

Since you cannot change your [static] IP at your hosting service, how
about implementing a proxy? Have some other e-mail account poll your
Comcast account, like have Hotmail or Gmail poll your Comcast account.
Then have your IMAP client poll the Hotmail or Gmail account. That way,
your IMAP client connects to somewhere other than Comcast, but which
polls your Comcast account. Yeah, it is a workaround, but it might
enable getting Comcast e-mail that you can't now.

>> Do you get an error when you attempt to telnet to their server just
>> to connect (not to send any IMAP commands)?
>
> Hm. I never thought to try.
>
> telnet imap.comcast.net 993
>
> Ok. I tried it with the Comcast ID username and with the email address
> as well, and escaping the @. It just hangs. I don't get a response. No
> prompt for a password.

I was wondering if you just got a connection from whatever IP address is
the one getting blocked. If that IP was blocked, I'd think you couldn't
even get a connection. As for getting the connection, 993 is the
SSL/TLS port. I'd see if they take 143, the non-encrypted port, so you
could enter commands in the telnet session. However, since you got the
connection, doesn't seem the IP address is blocked (if you used the one
that you thought was getting blocked).

From my home network, I can "telnet imap.comcast.net 143" to get
connected using the non-encrypted port, but that means they are not
blocking me by IP. Seems it is during the mail session when your IP (at
the hosted IMAP client) that gets rejected. Does your IMAP client there
let you keep a session log, so you could check if the connection is
getting rejected, or it gets connected, but the mail session gets
aborted?

Since your IMAP client is hosted at some service provider, not sure how
you could telnet from that IP unless the hoster gives you a shell for
that account.

>>Don't see complaining to Comcast is going to help since they're
>>blocking your hosting provider, not you.
>
> You really do have your fingers in your ears whenever I make statements.
> The IP address isn't blocked. The domain isn't blocked. The block is
> upon the two /24s their two IP addresses are in.

Illogical statement. Block is not on the IP address, but on an IP
address range that contains the IP address. Until Comcast, after
getting contacted by your hosting provider, decides not to block the IP
address, or the /range of IP addresses/ that your client uses, you can't
use your hosted IMAP client to access your Comcast account.

That's why I suggested a workaround using a proxy mail server that has a
completely different IP address. While it has happened, but only for
about a day, sometimes a major e-mail provider gets blocked by another
major provider, like when Gmail was blocking Hotmail for several hours.
They work out the problem pretty soon. You don't need to use
Hotmail/Outlook.com/Live or Gmail as a proxy. You could use Yahoo,
Inbox, Mail.com, or your pick. Just use one that has the feature to
poll another e-mail account.

> Very little email originates at this host and there are no spammers
> on the host.

In a subthread with Allo, he mentioned a bad actor could be defaming
your host provider with Comcast, and you agreed that could be the cause.
I said spammer instead of abuser or bad actor.

> You asked me before if it was blacklisted at any of the
> major third-party lists for being a spam source. It is not. I keep
> repeating myself.

That was to see if your IMAP client's IP was listed elsewhere than
Comcast. Odd that a bad actor focuses on just one target. Since it
was not listed elsewhere, it's just Comcast that doesn't like your
hosting service. So, a proxy using a major e-mail provider that is
highly unlikely to get blacklisted might be a viable workaround.

VanguardLH <V@nguard.LH> wrote:
>"Adam H. Kerman" <ahk@chinet.com> wrote:

>>Do you ever drop anything? DHCP is not in use. It is not a factor. DHCP
>>is irrelevant.

>So, all that noise insinuates that your IP address of your IMAP client
>(*wherever* it is) a static IP address. However, doesn't seem you get
>to decide its value. It is a static IP address assigned to your hosted
>client by the hosting provider (and not any IP assigned by them to your
>IMAP client).

Dear ghod, you refuse to list. I don't have a "hosting provider". It's a
host, period, that I have an account on. The IP address is that of the
host. It is NOT assigned to any client.

>Since you cannot change your [static] IP at your hosting service, how
>about implementing a proxy? . . .

These are fine suggestions that don't do me any good because if I
archive any email messages from the Comcast inbox, I want to save them
on that host. This is the reason I use IMAP.

>>>. . .
>I was wondering if you just got a connection from whatever IP address is
>the one getting blocked. If that IP was blocked, I'd think you couldn't
>even get a connection. As for getting the connection, 993 is the
>SSL/TLS port. I'd see if they take 143, the non-encrypted port, so you
>could enter commands in the telnet session.

Hm. In response to various commands, I got BAD IMAP COMMAND which tells
me which commands it's expecting, not telnet commands, heh. I'll have to
look those up. I got a little further than using the SSL port.

Good suggestion.

>. . Does your IMAP client there
>let you keep a session log, so you could check if the connection is
>getting rejected, or it gets connected, but the mail session gets
>aborted?

It's alpine, the successor client that grew up with IMAP. I can turn on
logging. I have to set aside time since it takes a very long time to
find what to look for.

>Since your IMAP client is hosted at some service provider, not sure how
>you could telnet from that IP unless the hoster gives you a shell for
>that account.

Yes, I have a shell.

>>>Don't see complaining to Comcast is going to help since they're
>>>blocking your hosting provider, not you.

>>You really do have your fingers in your ears whenever I make statements.
>>The IP address isn't blocked. The domain isn't blocked. The block is
>>upon the two /24s their two IP addresses are in.

>Illogical statement. Block is not on the IP address, but on an IP
>address range that contains the IP address.

I've written that very thing in multiple articles. The domain does not
have a bad reputation and it is not sending spam of any kind from its
Mail server.

>Until Comcast, after
>getting contacted by your hosting provider, decides not to block the IP
>address, or the /range of IP addresses/ that your client uses, you can't
>use your hosted IMAP client to access your Comcast account.

It's still not a "hosting provider". I'm not the administrator. I'm a
user on the host. The "hosting provider" is the server farm that the
administrator buys virtual hosting services from.

I'm the Comcast subscriber. They have to satisfy me.

Yeah, yeah, in my dreams.

>. . .

>>Very little email originates at this host and there are no spammers
>>on the host.

>In a subthread with Allo, he mentioned a bad actor could be defaming
>your host provider with Comcast, and you agreed that could be the cause.
>I said spammer instead of abuser or bad actor.

No, you misunderstood. If there is a bad actor spamming from a host on
an IP address in those two /24s, it's nothing to do with the reputation
of the domain in question. It's collateral damage.

>>You asked me before if it was blacklisted at any of the
>>major third-party lists for being a spam source. It is not. I keep
>>repeating myself.

>That was to see if your IMAP client's IP was listed elsewhere than
>Comcast.

It's not blacklisted on any major third-party list as a spam source. It
does not have a bad reputation score. Can you just accept this?

>Odd that a bad actor focuses on just one target. Since it
>was not listed elsewhere, it's just Comcast that doesn't like your
>hosting service. So, a proxy using a major e-mail provider that is
>highly unlikely to get blacklisted might be a viable workaround.

Really, that does not meet my needs.

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

>I filled out the form and received a generic reply that failed to
>address the situation, but promising to block the IP again if spam
>is once again detected, not having detected any from the host I use in
>the first place. . . .

Clearly, Comcast ignored the form. The blacklist entry must have been
lifted temporarily as I had a window in which to use IMAP, then it was
re-imposed.

Oh well.

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

> VanguardLH <V@nguard.LH> wrote:
>>"Adam H. Kerman" <ahk@chinet.com> wrote:
>
>>>Do you ever drop anything? DHCP is not in use. It is not a factor. DHCP
>>>is irrelevant.
>
>>So, all that noise insinuates that your IP address of your IMAP client
>>(*wherever* it is) a static IP address. However, doesn't seem you get
>>to decide its value. It is a static IP address assigned to your hosted
>>client by the hosting provider (and not any IP assigned by them to your
>>IMAP client).
>
> Dear ghod, you refuse to list. I don't have a "hosting provider". It's a
> host, period, that I have an account on. The IP address is that of the
> host. It is NOT assigned to any client.

It's not your host at home. It's not a host at a hosting provider. Oh,
it's just floating out there in the ether getting an IP address from the
angel cloud IP pool. Uh huh. It's a magical host.

You: "The hosts are virtual and live on a server farm".

And you operate that server farm owning all its resources? And, of
course, your IMAP client doesn't run on any host whether it be a
physical or virtual "host". An IMAP client doesn't care it is runs on a
physical or virtualized host.

So, you have no host on which to run your IMAP client. Just WHERE does
your IMAP client run? To provide networking, your virtual host has no
IP address seen by anywhere it connects? TCP doesn't work that way.

>>Since you cannot change your [static] IP at your hosting service, how
>>about implementing a proxy? . . .
>
> These are fine suggestions that don't do me any good because if I
> archive any email messages from the Comcast inbox, I want to save them
> on that host. This is the reason I use IMAP.

The proxy is the client to Comcast. The proxy is the server to which
your IMAP client connects. Don't use a POP proxy that just gets the
Inbox folder. Use an IMAP proxy. As an IMAP client, it gets e-mails in
the folders from your IMAP Comcast account. Your IMAP client gets
e-mails from the folder from the IMAP proxy. Of course, if you resort
to using an IMAP proxy that has a different IP, you might as well
consider moving your IMAP client to a different hosting provider, er,
server farm.

If you cannot find an IMAP proxy (and *not* ran on a virtual host at the
server farm, but somewhere else to ensure the IMAP server at Comcast
sees a completely different IP), how about going into your Comcast
account to enable forwarding? For e-mails sent to your Comcast account,
use auto-forward to send them elsewhere to where your host (virtual,
physical, or magical) with its IMAP client can connect. That only works
on new e-mails receiving into the Inbox to forward elsewhere, but then
anything you do for rules to move them into folder can also be done via
rules at the forwarded account using rules there (but include the To
header in those rules, so they only exercise on e-mails that originally
went to your Comcast account).

> Hm. In response to various commands, I got BAD IMAP COMMAND which tells
> me which commands it's expecting, not telnet commands, heh. I'll have to
> look those up. I got a little further than using the SSL port.
>
> Good suggestion.

For a non-encrypted connection, the next command is:

login <username> <password>

When I tried, I also get the bad command response. I can enter "list
capability", so some commands are accepted. I modified the command to:

a login <username> <password>

I got a bit further, but the server bitches it wants an SSL/TLS
connection to my client. That's likely because Comcast first forced use
of encrypted connections (port 993) and then enforced OAUTH2. So, you
can't get very far with telnet on port 143 other than to see that there
server allows or blocks a connection from your client's IP, and that's
all we're trying to test: can your host via whatever IP it gets from
your server farm on its external connection get to Comcast's IMAP server
without getting blocked. On an IP block, you'd never get telnet to get
the connection in the first place. It is later during the mail session
when their server decides not to communicate further. That's why I
mentioned a log by the IMAP client might show where the error happens.

> I've written that very thing in multiple articles. The domain does not
> have a bad reputation and it is not sending spam of any kind from its
> Mail server.

But I've seen where a mail server admin neglected to implement or update
their DNS nameserver to add SPF or DKIM records, or DMARC policies.
Some mail servers also refuse connections if the receiving mail server
has no MX (Mail Exchange) record at its nameserver showing which hosts
at the domain are authorized to receive e-mail. Could've been working
before, but somehow the DNS records were lost or corrupted.

At mxtoolbox.com, an MX lookup on comcast.net shows many hosts
authorized to receive e-mails, so your server farm will know to which it
connects for e-mail. I don't who is your server farm, so I can't test
if their SPF and DKIM records exist and are valid. While you are trying
to receive (IMAP) instead of send (SMTP), Comcast's blocking is more
likely oriented to sending issues to them from your server farm; i.e.,
they block all connects from a disreputable source.

I'm not sure spam is the only cause for blocking a sending mail server.

> No, you misunderstood. If there is a bad actor spamming from a host on
> an IP address in those two /24s, it's nothing to do with the reputation
> of the domain in question. It's collateral damage.

Thanks for the delineation between IP and domain name, but the domain is
still operated under an IP pool of a suspicious service. If the service
is rated disreputable, so are the domains hosted there. The good babies
are tossed out with the bath water.

I've run into this with censorware. My company use some censoring
service (was "Web<something>", like maybe WebSense) to regulate to where
their employees could connect outside the corporate network. I'd do
research on a solution to find a site that had some information, but I
couldn't tell if it was helpful or not, because I couldn't connect
there. The web hoster was blacklisted (I think it was in a porn
category), so I couldn't get to any sites by any domain name at that
webhoster. Best I could do was contact IT to get them to request an
exclusion for our company on that domain at that webhosting provider,
but IT decided my need wasn't sufficient to unblock the webhoster to
allow their employees to see porn while at work. So, I had to look
elsewhere for help. I couldn't even look at their site to see how to
contact them to notify they were being censored as a site running at a
porn category service.

>>Odd that a bad actor focuses on just one target. Since it
>>was not listed elsewhere, it's just Comcast that doesn't like your
>>hosting service. So, a proxy using a major e-mail provider that is
>>highly unlikely to get blacklisted might be a viable workaround.
>
> Really, that does not meet my needs.

But neither is your current server farm service doling out that virtual
host for you to run an IMAP client there.

I've used a Hotmail account to poll reserve (not monitored) accounts are
Gmail, and a Gmail account to poll reserve accounts at Hotmail. The
logins are needed to keep alive the as-yet-unused reserved accounts. At
first, and just in case any e-mails were sent to my reserved accounts, I
enabled their auto-forward option to transfer e-mails received in my
reserved accounts to my live accounts. However, I decided what I got in
the reserved accounts was spam or garbage, so I disabled auto-forward,
and defined a rule that discarded all e-mails received in a reserved
account.

I know (since I also tried this) where some folks will compound the spam
filtering at multiple e-mail providers. Perhaps the e-mail service they
wanted to use as primary did not have very good spam filtering, and
those users didn't want to construct a anti-spam setup on their own
workstations. So, they would have e-mails sent to Gmail to get
forwarded to their regular account, or they forwarded e-mails to their
regular account to their Gmail account. This added another layer of
spam filtering: some at one e-mail provider, and more at another.

Instead of your IMAP client polling your Comcast account, you change it
to poll, say, a Gmail account. Your Hotmail account forwards its
e-mails to your Gmail account, and your IMAP client polls your Gmail
account. Or, have your Gmail account poll your Comcast account, and
your IMAP client polls Gmail. You add one more hop in e-mail delivery.

You could use a workaround, or suffer with your current scenario of
getting blocked. One is doable solution. The other is a dead
non-solution. Your choice. Get those e-mails, or don't.

VanguardLH <V@nguard.LH> wrote:
>"Adam H. Kerman" <ahk@chinet.com> wrote:
>>VanguardLH <V@nguard.LH> wrote:
>>>"Adam H. Kerman" <ahk@chinet.com> wrote:

>>>>Do you ever drop anything? DHCP is not in use. It is not a factor. DHCP
>>>>is irrelevant.

>>>So, all that noise insinuates that your IP address of your IMAP client
>>>(*wherever* it is) a static IP address. However, doesn't seem you get
>>>to decide its value. It is a static IP address assigned to your hosted
>>>client by the hosting provider (and not any IP assigned by them to your
>>>IMAP client).

>>Dear ghod, you refuse to list. I don't have a "hosting provider". It's a
>>host, period, that I have an account on. The IP address is that of the
>>host. It is NOT assigned to any client.

>It's not your host at home.

It's not my host at all. I'm a user. The administrator is the customer
of the hosting provider. If you listened to what I said the very first
time, you'd have understood this. It's not difficult.

>>. . .

>>No, you misunderstood. If there is a bad actor spamming from a host on
>>an IP address in those two /24s, it's nothing to do with the reputation
>>of the domain in question. It's collateral damage.

>Thanks for the delineation between IP and domain name, but the domain is
>still operated under an IP pool of a suspicious service.

This is the only host the administrator runs. The others hosts in those
two /24s have nothing to do with him. There's nothing wrong with the
server farm's reputation. Would you knock off the baseless accusations?

>If the service is rated disreputable, . . .

It's just not. You made shit up.

>>>Odd that a bad actor focuses on just one target. Since it
>>>was not listed elsewhere, it's just Comcast that doesn't like your
>>>hosting service. So, a proxy using a major e-mail provider that is
>>>highly unlikely to get blacklisted might be a viable workaround.

>>Really, that does not meet my needs.

>But neither is your current server farm service doling out that virtual
>host for you to run an IMAP client there.

Try to understand. I am not the customer of the server farm.

>I've used a Hotmail account to poll reserve (not monitored) accounts are
>Gmail, and a Gmail account to poll reserve accounts at Hotmail.

I've gotten through betweem long instances of being blacklisted, so I
don't need to prove that Comcast has IMAP enabled from foreign networks.

>. . .

>Instead of your IMAP client polling your Comcast account, you change it
>to poll, say, a Gmail account. Your Hotmail account forwards its
>e-mails to your Gmail account, and your IMAP client polls your Gmail
>account. Or, have your Gmail account poll your Comcast account, and
>your IMAP client polls Gmail. You add one more hop in e-mail delivery.

Yes, I realize that's possible. It's just not worth it for an account I
barely use.

>You could use a workaround, or suffer with your current scenario of
>getting blocked. One is doable solution. The other is a dead
>non-solution. Your choice. Get those e-mails, or don't.

I use the Web server on occassion.

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

> It's not my host at all. I'm a user. The administrator is the customer
> of the hosting provider. If you listened to what I said the very first
> time, you'd have understood this. It's not difficult.

You're not paying anything to have this virtual host on a server farm?
It's a freebie someone gave you to use?

> Try to understand. I am not the customer of the server farm.

And yet you claim your IMAP client is running on a virtual host at that
server farm, but apparently you don't own it or admin it, and someone
else does all the work for you, but that person won't resolve the block.

> I use the Web server on occassion.

That's another workaround, too.

VanguardLH <V@nguard.LH> wrote:
>"Adam H. Kerman" <ahk@chinet.com> wrote:

>>It's not my host at all. I'm a user. The administrator is the customer
>>of the hosting provider. If you listened to what I said the very first
>>time, you'd have understood this. It's not difficult.

>You're not paying anything to have this virtual host on a server farm?
>It's a freebie someone gave you to use?

I refuse to answer on the grounds that you aren't listening. See the
very same answer I gave in pretty much every single article and followup
I wrote in this thread. The rest snipped. Vanguard, it's impossible to
have a conversation with you.

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

> VanguardLH <V@nguard.LH> wrote:
>>"Adam H. Kerman" <ahk@chinet.com> wrote:
>
>>>It's not my host at all. I'm a user. The administrator is the customer
>>>of the hosting provider. If you listened to what I said the very first
>>>time, you'd have understood this. It's not difficult.
>
>>You're not paying anything to have this virtual host on a server farm?
>>It's a freebie someone gave you to use?
>
> I refuse to answer on the grounds that you aren't listening. See the
> very same answer I gave in pretty much every single article and followup
> I wrote in this thread. The rest snipped. Vanguard, it's impossible to
> have a conversation with you.

Yep, when you decide you want help on a secret you keep. Guess you're
stuck with their webmail client.

Adam H. Kerman wrote:
> I filled out the form and received a generic reply that failed to
> address the situation, but promising to block the IP again if spam
> is once again detected, not having detected any from the host I use in
> the first place.
>
> The Comcast address isn't used for any mission-critical email, just service
> related email from Comcast and a few specific utilities.
>
> It would be a bad idea to rely upon the Comcast address for anything. If
> you're out of town, then you'll be using IMAP from a network Comcast
> doesn't recognize and possibly subject to the temporary blacklist.

Comcast customer for 20+ years.
I take a laptop when traveling and never had a problem with Comcast's servers.

El Sinonimo <el@sinonimo.mx> wrote:
>Adam H. Kerman wrote:

>>I filled out the form and received a generic reply that failed to
>>address the situation, but promising to block the IP again if spam
>>is once again detected, not having detected any from the host I use in
>>the first place.

>>The Comcast address isn't used for any mission-critical email, just service
>>related email from Comcast and a few specific utilities.

>>It would be a bad idea to rely upon the Comcast address for anything. If
>>you're out of town, then you'll be using IMAP from a network Comcast
>>doesn't recognize and possibly subject to the temporary blacklist.

>Comcast customer for 20+ years.
>I take a laptop when traveling and never had a problem with Comcast's servers.

I must have missed the part in which you stated you were using IMAP from
a shell account on a foreign network. If you're not, how is your
experience relevant to mine?

Adam H. Kerman wrote:
> El Sinonimo <el@sinonimo.mx> wrote:
>> Adam H. Kerman wrote:
>>> I filled out the form and received a generic reply that failed to
>>> address the situation, but promising to block the IP again if spam
>>> is once again detected, not having detected any from the host I use in
>>> the first place.
>>> The Comcast address isn't used for any mission-critical email, just service
>>> related email from Comcast and a few specific utilities.
>>> It would be a bad idea to rely upon the Comcast address for anything. If
>>> you're out of town, then you'll be using IMAP from a network Comcast
>>> doesn't recognize and possibly subject to the temporary blacklist.
>> Comcast customer for 20+ years.
>> I take a laptop when traveling and never had a problem with Comcast's servers.
> I must have missed the part in which you stated you were using IMAP from
> a shell account on a foreign network. If you're not, how is your
> experience relevant to mine?

If you're not smart enough to configure an IMAP client, use webmail.

El Sinónimo <el@sinonimo.mx> wrote:

> If you're not smart enough to configure an IMAP client, use webmail.

The blocking is not due to misconfigure of settings for server in the
IMAP client. It's the IMAP client's IP address that is getting blocked,
and there are no client settings to specify the host's IP address.

VanguardLH <V@nguard.LH> wrote:
>El Sinonimo <el@sinonimo.mx> wrote:

>>If you're not smart enough to configure an IMAP client, use webmail.

>The blocking is not due to misconfigure of settings for server in the
>IMAP client. It's the IMAP client's IP address that is getting blocked,
>and there are no client settings to specify the host's IP address.

Please don't interfere with the idiot trying to start a flame war with me.
We can let him be.