Post by Adam H. KermanPost by VanguardLHPost by Adam H. KermanDo 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.
Post by Adam H. KermanPost by VanguardLHSince 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).
Post by Adam H. KermanHm. 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.
Post by Adam H. KermanI'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.
Post by Adam H. KermanNo, 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.
Post by Adam H. KermanPost by VanguardLHOdd 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.