Email not delivered

[Nil]

I know this is a long shot, I know, but can anyone suggest a reason
this email was not delivered? It's to a friend in San Diego who I last
emailed about three weeks ago. I believe his email service has been
with Roadrunner, which seems to have gone through many name and owner
changes. It appears that they may now be called "Spectrum" and were
previously either Time-Warner or Charter. I resent the message about 10
hours ago from gmail and haven't heard anything yet, either from the
mail server or from him.

This non-delivery notice isn't very helpful, but maybe someone sees
something I don't?

========================

Date: Mon, 25 Jun 2018 18:11:49 +0000
From: mailer...@comcast.net
To: (me)@comcast.net
Subject: Permanent Error

This is an automatically generated Delivery Status Notification.

Delivery to the following recipients failed permanently:

* (redacted)@san.rr.com

Reason: Permanent Error

Reporting-MTA: dns; resqmta-ch2-11v.sys.comcast.net [69.252.207.43]
Received-From-MTA: dns; resomta-ch2-17v.sys.comcast.net
[69.252.207.113]

Arrival-Date: Mon, 25 Jun 2018 18:11:49 +0000
Final-recipient: rfc822; (redacted)@san.rr.com
Diagnostic-Code: smtp; 554 dnvrco-cmimta01 esmtp ESMTP server not
available AUP#I-1000

Last-attempt-Date: Mon, 25 Jun 2018 18:11:49 +0000

[VanguardLH]

"Permanent error" could mean the account no longer exists or is
suspended (for abuse). To test if the e-mail address is still valid,
you can issue SMTP commands to establish a session with the target's
mail server and send the RCPT TO command to see if the mail server
recognizes that account as valid. Instead you could use an online
e-mail validation service to do the same check, like:

https://www.ip-address.org/verify/email-checker.php
https://verify-email.org/

Some e-mail providers block these e-mail validators since they can be
used by spammers to cull valid addresses from those providers. Since I
don't have the full e-mail address to specify at an e-mail validation
service (to find out if RR responds with OK or ERR status or if RR even
allows the validation services to query their SMTP server), I cannot
check if the recipient's account still exists (which could be due to an
account deletion or a suspended account made invisible). Do NOT reveal
the recipient's username in their e-mail address here. Just use one of
the e-mail validation services yourself to check if the recipient's
e-mail address is still valid at RR.

Another reason an e-mail account refuses to accept new e-mails is the
account's disk quota has been consumed. If the recipient has a 10GB
mailbox but it currently has 10GB of messages in it then that account
can not accept any further e-mails. That happens most often when
senders attempt to use e-mail as a file transfer service when they
should instead be uploading the file and including a URL to point at the
uploaded file. The former method makes messages huge not just because
of the size of the attached file but also because ALL e-mail gets sent
as plain text. Attachments get encoded into a long text string and are
recorded within MIME sections within the body of the e-mail. E-mail has
no resume function nor any check the e-mail is complete as it was NEVER
intended for use for file transfers. Yet senders keep attaching a slew
of photos at high resolution or other huge files making their message
too large for the recipient. E-mail accounts have quotas, like the
total amount of disk space for the entire mailbox and the maximum size
of each message. You didn't mention the size of your message. If the
recipient's mailbox is full, they will have to delete some messages
before new ones can be accepted.

The following error mentioned in the NDR (non-delivery report) hints
there is a problem at the recipient's mail server:

Diagnostic-Code: smtp; 554 dnvrco-cmimta01 ...

One, that is not a valid hostname. The recipient's mail server should
have hostname.domain.tld for its syntax for a proper DNS lookup. Humans
like names. Computers demand numbers, so the sending mail server has to
use DNS to get the IP address of the receiving mail server. You said
the recipient's e-mail address is:

<them>@san.rr.com

You sure "san." is supposed to be included in the recipient's e-mail
address? Typically just the domain is specified, not a hostname at that
domain. The sending mail server queries the DNS server for an "MX"
record (mailbox) that has the domain specify what is a valid mail server
at that domain.

https://en.wikipedia.org/wiki/MX_record

I went to https://mxtoolbox.com/ and entered rr.com. It says one of the
MX records points to dnvrco-postmx01.email.rr.com. That's close to the
hostname mentioned in the Diagnostic-Code status but which is missing
the ".email.rr.com" to specify the domain (could be Comcast truncated
the FQDN down to just the hostname). A 554 error code got returned by
Comcast's outgoing mail server.

https://postmaster.comcast.net/smtp-error-codes.php
554 - [PTR lookup failure]
- Comcast requires all sending mail server IP addresses have a valid PTR
record set up. This error results when the lookup failed.
- NXDOMAIN response. One of the authoritative servers for the relevant
section of the in-addr.arpa DNS tree is saying that there is no PTR
record for the given IP address

PTR records are the IP addresses for the hostname (host.domain.tld) from
a DNS lookup. When you go to www.intel.com, the PTR record returns what
is the hostname for an IP address. It is a reverse DNS lookup: give an
IP address and get back a hostname. Users running mail servers on their
own home PCs are running DNS servers to offer an A record (lookup
hostname from given IP address) to then offer a PTR record (lookup IP
address from hostname). It is a means of testing for invalid or
unauthorized mail servers often ran by spammers or scammers. See:

https://www.cloudns.net/wiki/article/40/

Some e-mail providers also require an e-mail provider to list an MX
record showing they have a host they declare as their outgoing mail
server. Lack of a PTR record to match against an A record and lack of
an MX record hints to an invalid server.

You sure the recipient's e-mail address should be @san.rr.com and not
just @rr.com? san.rr.com might what a user specifies when defining
their e-mail account as to what server their e-mail client connects.
That doesn't mean it is part of their e-mail address. Comcast uses
smtp.comcast.net, imap.comcast.net, and pop.comcast.net for their mail
server names but your Comcast e-mail address' domain does not contain
smtp, imap, or pop, just the comcast.net part. I suspect san.rr.com is
the mail server to which that user connects to receive and send e-mails.
It is usually NOT part of their e-mail address. Could be RR
regionalized their e-mail addresses as a means to load balance their
e-mail traffic but that Spectrum is better setup to pass e-mail traffic
to the appropriate regionalized SMTP server. Using mail server
hostnames to load balancing is a poor choice for regionalizing of load
balance of e-mail traffic. It prevents redistribution of load balancing
by slicing up, merging, or creating region names. They're stuck with
how they originally decided to regionalize.

Got any other means of contacting this recipient, like phone or chat or
text, to make sure you have their correct and current e-mail address?
TWC launched RoadRunner in 1995. TWC dropped "RoadRunner" and just went
with TWC branding in 2012. Charter acquired TWC in 2016. Charter
rebranded TWC aka RoadRunner as Spectrum. Could be you use rr.com
instead of san.rr.com or now use some completely different domain name
in the old RR customers' e-mail addresses. Could be TWC screwed up
Spectrum's DNS records, like no matching PTR for A record and no MX
record; however, that would result in a LOT of senders not being able to
get their e-mails to RR/TWC/Charter/Spectrum customers. As a sender
using a different e-mail provider, you complaining to Spectrum would
have no effect. They need to open tickets from their own customers, and
why I asked if you have any other communications venue to that recipient
as they'll have to open an issue ticket with their provider.

You could see if Comcast can kick Spectrum in the ass to fix their A,
PTR, or MX records. Comcast isn't the only e-mail provider requiring a
PTR record to validate a mail server. Some even test for a valid MX
record. Comcast techs might know who to contact at Spectrum: Comcast
could check the DNS records for Spectrum and report to Spectrum any
problems they found in Spectrum's DNS records.

Seems Comcast refuses to go there because there doesn't validate itself
properly as an authorized mail server.

[Nil]

On 25 Jun 2018, VanguardLH <V...@nguard.LH> wrote in
alt.online-service.comcast:

> https://verify-email.org/

According to this site, the address is valid. If it had become invalid
it would have been within the past couple of weeks. And Gmail accepted
the address and seems to have successfully sent an email there.

> Another reason an e-mail account refuses to accept new e-mails is
> the account's disk quota has been consumed.

Doubtful, but I'm checking on it. Too bad the error message isn't more
descriptive. If nothing else, they'd be saving themselves a lot of
support staff time.

> You sure "san." is supposed to be included in the recipient's
> e-mail address?

I can only say that that address has worked for years or decades. If a
recent corporate reorganization has suddenly made legacy email account
inaccessible, I don't know.

> You sure the recipient's e-mail address should be @san.rr.com and
> not just @rr.com?

"Has been"? Certainly. "Should be"? I don't know. I did just send a
test email to <him>@rr.com and it failed with the same error message.

> Got any other means of contacting this recipient, like phone or
> chat or text, to make sure you have their correct and current
> e-mail address?

Yes, of course, and I will soon. But he's probably not tech-savvy
enough to understand the question, much less the answer. Tho, maybe
he's been having other email issues lately...

> As a sender using a
> different e-mail provider, you complaining to Spectrum would have
> no effect.

Indeed, I can't even find an email address for them. They seem to only
communicate with paying customers.

> You could see if Comcast can kick Spectrum in the ass to fix their
> A, PTR, or MX records.

Shirley, you jest!

[VanguardLH]

Nil wrote:

> VanguardLH wrote:
>
>> Another reason an e-mail account refuses to accept new e-mails is the
>> account's disk quota has been consumed.
>
> Doubtful, but I'm checking on it. Too bad the error message isn't more
> descriptive.

They never are. None of highly focused. The error codes are used as
catch-all groups into which many error causes are aggregated. Only if
the postmaster defines a list of comment strings for each error and then
appends the comment string to the error code they return would they be
usable descriptions. Never works out that way though.

>> Got any other means of contacting this recipient, like phone or
>> chat or text, to make sure you have their correct and current
>> e-mail address?
>
> Yes, of course, and I will soon. But he's probably not tech-savvy
> enough to understand the question, much less the answer. Tho, maybe
> he's been having other email issues lately...

You might want to give him the URL to the Comcast article stipulating
that Comcast requires a mail server to have a PTR record in that
domain's nameserver (DNS) [that then propagates to other nameservers].
He doesn't have to understand the article but he will have ammunition to
fire at Spectrum noting why Comcast refuses to connect to Spectrum.

>> You could see if Comcast can kick Spectrum in the ass to fix their
>> A, PTR, or MX records.
>
> Shirley, you jest!

Nope. I've contacted Comcast before (which requires getting past the
1st level tech reading canned replies from a database into which they
inject keywords) about other e-mail providers not having a valid PTR
record. E-mail providers often have to contact each other to resolve
accessibility or deliverability problems. Seems Spectrum recently
screwed something up which means they will have problems with more than
just Comcast as a sending source. Doing a reverse DNS lookup (requiring
the PTR record) and even adding an MX lookup are means of weeding out
the "personal" mail servers, and also why SPF and DomainKeys are used.
Admins make mistakes, so Spectrum could've screwed their DNS records.
You and me don't directly interface with any e-mail provider except as
their customer. You need to get one e-mail provider to notify the other
one that the other one needs to fix or improve their e-mail setup. I've
done the same using feedback with Hotmail to get them to work with other
e-mail providers to resolve a problem. I had a routing problem with a
dead host as a node in the path but the routing table wasn't getting
dynamically updated to get around the dead node. A call to Comcast got
them to update their routing table which propagated a new path and,
voila, I could connect to the other end.

If you don't try, you're guaranteed to fail. A restaurant manager will
know service is bad unless his patrons tell him. Chintzing on the tip
only tells the waitress assuming she gets the point, but that doesn't
notify the manager and the waitress isn't going to tell him.

I know lots of users complain that cannot get Comcast to fix any
problem. I've not had that problem but I'm guessing that I am a hell of
lot more persistent than the average user. Never get irate with the 1st
level tech; else, you shoot yourself in your own foot trying to get it
into the door. You need a trouble ticket get issued AND you need to
follow up on it. Giving them reasonable details to reproduce the
problem also helps. Pretty tough to troubleshoot something vague.

Most e-mail providers have a default e-mail address to contact their
e-mail admin, like postmaster@<domain>. It's a de factor default e-mail
address; however, that doesn't mean they monitor that address. Spam
abuse reports may also go there, so they use a bot to process the
inbound spam exhibits. However, typical the spam reporting e-mail
address is abuse@<domain>.

At https://www.spectrum.net/contact-us/, you can enter your zipcode (as
long as it is within a TWC/Charter service area) and use chat to see if
you can open an issue ticket that way as a non-customer. I suspect
you'll get nowhere with Spectrum since you are not their customer, and
why I suggest your recipient has to open the ticket.

You might find if anyone else with the same problem has reported it in
the TWC forums. I found one such problem report at:

https://forums.timewarnercable.com/t5/Email/help-with-error-SMTP-error-554-dnvrco-cmimta15-esmtp-ESMTP/td-p/142192

If TWC/Charter/Spectrum had really screwed up their SMTP server, I would
think there would be a flood on online search matches of masses of
non-RR users reporting they cannot get their e-mails delivered to RR
users. I didn't see that, so I suspect the problem is with the
recipients RR account, and it's like only that recipient as a customer
of Spectrum can get the issue identified and resolved.

All quota consumed or received messages too big are not the only reasons
senders cannot get their messages delivered to a recipient. The
recipient's account could be deleted or suspended. Deletion is usually
not immediate: the account remains in delete state for awhile, so
querying their SMTP server about the recipient's e-mail address doesn't
have the SMTP server immediately declare the recipient as unknown or
invalid. Sending spam is another cause for suspending an e-mail
account. Even getting too many bouncebacks is indicative of an account
used for spamming: the spammer or bulk mailer is sending to way too many
invalid, inactive, or dead e-mail addresses resulting in lots of
bouncebacks that the sender's mail server must handle. I forget for
which of my e-mail accounts but too many bouncebacks (something 6 per
hour) means I'm sending to an inaccurate list of recipients and that's
typical of bulk mailings. The sender using a mailing list has defunct
entries, they don't maintain that list, or they're a spammer generating
random e-mail addresses or those harvested from flaky sources (e.g.,
Usenet posts). Your recipient may not realize he has exceeded some
anti-spam quota, or that someone hacked into his account and spammed
from there. If he doesn't send e-mail or monitoring it regularly, he
may not even know his account got suspended. He needs to check. For
example, use Spectrum's webmail client to login and check he can send
and to test sends from other e-mail providers (e.g., Gmail) to check he
can receive.

[Barry Margolin]

In article <XnsA90C9CAF...@wheedledeedle.moc>,

Here's a TWC forum thread about the AUP#I-1000 rejection message:

https://forums.timewarnercable.com/t5/Email/help-with-error-SMTP-error-55
4-dnvrco-cmimta15-esmtp-ESMTP/td-p/142192

If I understand it correctly, it means that the TWC server is blocking
the Comcast server.

I tried looking up the server at their block lookup tool

http://postmaster.rr.com/amIBlockedByRR

but it has a broken CAPTCHA and won't allow any submissions.

--
Barry Margolin
Arlington, MA

[Bruce Esquibel]

VanguardLH <V...@nguard.lh> wrote:

> The following error mentioned in the NDR (non-delivery report) hints
> there is a problem at the recipient's mail server:

> Diagnostic-Code: smtp; 554 dnvrco-cmimta01 ...

> One, that is not a valid hostname. The recipient's mail server should

It's not valid because comcast truncated the message...

dig -t mx san.rr.com

san.rr.com. 600 IN MX 10 dnvrco-cmedge02.email.rr.com.
san.rr.com. 600 IN MX 10 dnvrco-cmedge01.email.rr.com.

So @san.rr.com is a valid place to send email to and comcast didn't print
the full server name.

It's probably comcasts fault being they returned the 5.x.x error message,
they didn't figure out the host address or were having some other dns problem.

For what it's worth, I just emailed a test message...

----- Transcript of session follows -----
... while talking to dnvrco-cmedge01.email.rr.com.:
>>> RCPT To:<billm...@san.rr.com>
<<< 550 5.1.1 <billm...@san.rr.com> recipient rejected
550 5.1.1 <billm...@san.rr.com>... User unknown
>>> DATA
<<< 503 5.5.0 need RCPT before DATA

and it came back correctly (user unknown) but not a failure because it spoke
to the end smtp receiver.

So either when you sent that message to your friend comcast failed looking
up the correct MX records or those two servers for san.rr.com were down or
in maintance mode.

Either way, a 5.x.x means you have to try again, the original message is
not going to be retried.

-bruce
b...@ripco.com

[VanguardLH]

Bruce Esquibel wrote:

> VanguardLH wrote:
>
>> The following error mentioned in the NDR (non-delivery report) hints
>> there is a problem at the recipient's mail server:
>
>> Diagnostic-Code: smtp; 554 dnvrco-cmimta01 ...
>
>> One, that is not a valid hostname. The recipient's mail server should
>
> It's not valid because comcast truncated the message...

Which duplicates my presumption in the part you snipped, which was:

I went to https://mxtoolbox.com/ and entered rr.com. It says one of
the MX records points to dnvrco-postmx01.email.rr.com. That's close
to the hostname mentioned in the Diagnostic-Code status but which is
missing the ".email.rr.com" to specify the domain (could be Comcast
truncated the FQDN down to just the hostname).

Yes, I'm verbose, so you probably missed that.

[Nil]

On 26 Jun 2018, Barry Margolin <bar...@alum.mit.edu> wrote in
alt.online-service.comcast:

> Here's a TWC forum thread about the AUP#I-1000 rejection message:
>
> https://forums.timewarnercable.com/t5/Email/help-with-error-SMTP-error-55 4-dnvrco-cmimta15-esmtp-ESMTP/td-p/142192
>
> If I understand it correctly, it means that the TWC server is
> blocking the Comcast server.

That thread seems to describe my symptoms pretty accurately.

> I tried looking up the server at their block lookup tool
>
> http://postmaster.rr.com/amIBlockedByRR
>
> but it has a broken CAPTCHA and won't allow any submissions.

Still broken when I tried it just now. Too bad - it could be a
useful tool.

But! Good news I hope: I can now send email to that address and it
does NOT bounce back, at least not yet after about 4 hours. My
friend has not responded yet, but signs are hopeful.

[Barry Margolin]

In article <XnsA90E4F6...@wheedledeedle.moc>,

Comcast has multiple servers, and maybe just one of them is on TWC's
block list.

[Nil]

On 27 Jun 2018, Barry Margolin <bar...@alum.mit.edu> wrote in
alt.online-service.comcast:

> Comcast has multiple servers, and maybe just one of them is on
> TWC's block list.

Or maybe one of them was down or misconfigured and has since been put
right. In any case, my friend and I are now trading emails through
Comcast, so for the time being the problem has disappeared. I continue
to watch closely.

Thanks for your help.

[VanguardLH]

Nil wrote:

> Barry Margolin wrote:
>
>> Comcast has multiple servers, and maybe just one of them is on
>> TWC's block list.
>
> Or maybe one of them was down or misconfigured and has since been put
> right. In any case, my friend and I are now trading emails through
> Comcast, so for the time being the problem has disappeared. I continue
> to watch closely.
>
> Thanks for your help.

I just checked and the RR mail server (I only checked one) did have a
PTR record. I didn't check for my first reply. Could be TWC was doing
maintenance or server changes and didn't get their nameserver updated.
Comcast won't connect with an MTA (mail transfer agent) that doesn't
have a PTR record; see:

https://postmaster.comcast.net/smtp-error-codes.php
(noted in my first reply)

Comcast issued the 554 error response but that was due to invalid
configuration of the nameserver records established by the receiving
MTA. It's not just a Comcast requirement an MTA have a PTR record but
of many other e-mail providers, too. Microsoft has the same PTR record
requirement for the receiving MTA.

https://support.microsoft.com/en-us/help/300171/you-are-unable-to-send-or-receive-smtp-messages-from-certain-internet

MTAs should have static IP addresses. Dynamic IP addresses highly
indicate it is for a customer host, not a commercial server. Requiring
a PTR record to show the MTA has a static address is one way of
filtering out all the users running SMTP servers on their home PCs that
get dynamic IP addresses. A PTR record proves the identity of the
server (just the host itself, not of any hosted domains on that server).

A PTR record is just one check. It's just one check to eliminate rogue
MTAs. No one check is failproof, so protections are compounded, like
using SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail)
or DMARC (Domain-based Message Authentication, Reporting and
Conformance). Requiring an MX record is another check to prove that
domain has a nameserver record showing there is an authorized receiving
MTA at that domain. Because of the reliance on DNS for these
protections, DNS spoofing (aka DNS [cache] poisoning) must be avoided.
DNS isn't just used to find web sites but that is often what gets
noticed in the press; for example:

https://www.calyptix.com/top-threats/3-common-dns-attacks-and-how-to-fight-them/

Blacklisting an ISP's or other high-volume commercial e-mail provider
would result in a huge number of NDR (Non-Delivery Reports). That can
by itself alert the sending MTA to contact the receiving MTA to resolve
the problem. Accounts can get suspended because they generate far too
many NDRs, like spammers using harvested e-mail addresses in which many
or most are invalid or fake e-mail addresses resulting in NDRs when the
spammer decides to spew their mega-load of turds. Since there are
monitors watching accounts for excessive NDRs, there are also monitors
watching for aggregate NDR counts across all accounts to alert staff
there is a delivery problem for them as the source. A flood of user
complaints reporting the NDRs. That's why I mentioned notifying your
e-mail provider of an unresolvable NDR. With SPF, DKIM, or DMARC, a
professional e-mail provider should already know via whitelisting which
MTAs they should never be blacklisting but fuckups happen, especially
when you bring in new-hires during any major changes.

[Barry Margolin]

In article <thmcu23q...@v.nguard.lh>, VanguardLH <V...@nguard.LH>
wrote:

> Nil wrote:
>
> > Barry Margolin wrote:
> >
> >> Comcast has multiple servers, and maybe just one of them is on
> >> TWC's block list.
> >
> > Or maybe one of them was down or misconfigured and has since been put
> > right. In any case, my friend and I are now trading emails through
> > Comcast, so for the time being the problem has disappeared. I continue
> > to watch closely.
> >
> > Thanks for your help.
>
> I just checked and the RR mail server (I only checked one) did have a
> PTR record. I didn't check for my first reply. Could be TWC was doing
> maintenance or server changes and didn't get their nameserver updated.
> Comcast won't connect with an MTA (mail transfer agent) that doesn't
> have a PTR record; see:

Go back and read the original post. It was a TWC error complaining about
the Comcast sending server, not a Comcast error complaining about the
TWC receiving server.

Maybe you were confused because the "Reporting-MTA" was Comcast. But it
was reporting an error code it received from the TWC server.

[VanguardLH]

Barry Margolin wrote:

> In article <thmcu23q...@v.nguard.lh>, VanguardLH <V...@nguard.LH>
> wrote:
>
>> Nil wrote:
>>
>>> Barry Margolin wrote:
>>>
>>>> Comcast has multiple servers, and maybe just one of them is on
>>>> TWC's block list.
>>>
>>> Or maybe one of them was down or misconfigured and has since been put
>>> right. In any case, my friend and I are now trading emails through
>>> Comcast, so for the time being the problem has disappeared. I continue
>>> to watch closely.
>>>
>>> Thanks for your help.
>>
>> I just checked and the RR mail server (I only checked one) did have a
>> PTR record. I didn't check for my first reply. Could be TWC was doing
>> maintenance or server changes and didn't get their nameserver updated.
>> Comcast won't connect with an MTA (mail transfer agent) that doesn't
>> have a PTR record; see:
>
> Go back and read the original post. It was a TWC error complaining about
> the Comcast sending server, not a Comcast error complaining about the
> TWC receiving server.

In the NDR mentioned by the OP:

"From: mailer...@comcast.net"

and ||
VV

"Delivery to the following recipients failed permanently:
* (redacted)@san.rr.com"

and

"Reporting-MTA: dns; resqmta-ch2-11v.sys.comcast.net ..."

and

"Diagnostic-Code: smtp; 554 dnvrco-cmimta01 esmtp ESMTP server not

available" ^^^^^^^^^^^^^^^
that was RR's server -----'

- Comcast's server sent the NDR, not RR/TWC's server.
- The NDR was about non-delivery *to* an RR recipient, not that RR
refused a connection from Comcast.
- Comcast was the reporting MTA - because they didn't get a PTR record
for RR's server.
- The diag line reports the dnvrco-cmimta01 server was not available,
and that's RR's server, not Comcast's.

TWC never reported anything because Comcast refused to establish a
session with their MTA.

> Maybe you were confused because the "Reporting-MTA" was Comcast. But it
> was reporting an error code it received from the TWC server.

Oh, so TWC was reporting that it was TWC's server that was not
available? If TWC's server was not available then it wouldn't be
issuing an NDR.

[Barry Margolin]

In article <h06autscxbze$.dlg@v.nguard.lh>, VanguardLH <V...@nguard.LH>
wrote:

Yes.

> - The NDR was about non-delivery *to* an RR recipient, not that RR
> refused a connection from Comcast.
> - Comcast was the reporting MTA - because they didn't get a PTR record
> for RR's server.
> - The diag line reports the dnvrco-cmimta01 server was not available,
> and that's RR's server, not Comcast's.

No, what it reports is that while trying to send the message to
dnvrco-cmimta01, it replied with a 554 error code. The entire message
was:

"Diagnostic-Code: smtp; 554 dnvrco-cmimta01 esmtp ESMTP server not

available AUP#I-1000"

If you check the forum link I posted earlier, AUP#I-1000 is a TWC error
code, not a Comcast error code. I think Comcast's servers use codes with
3 numbers separated by decimal points.

[VanguardLH]

A server can report that it is down? Of course, "not available" could
mean just the server program on a host is not available (hung, not
running, unresponsive) and some other frontend server is reporting that
it cannot communicate with the mail server. "Not available" is vague.

> If you check the forum link I posted earlier, AUP#I-1000 is a TWC error
> code, not a Comcast error code. I think Comcast's servers use codes with
> 3 numbers separated by decimal points.

I linked to that same forum thread 10 hours before you in another
subthread. That poster was trying to use a private SMTP server which
would likely not have a PTR record in TWC's nameserver hence why that
poster had problems with TWC accepting his private SMTP as a sending
MTA. TWC was treating this private SMTP sending server similar to how
Comcast or Microsoft or many others would treat the TWC receiving SMTP
servers that didn't have a valid PTR record.

One poster there noted the TWC servers were getting "moved" (but unclear
what that entailed) and problems with *TWC* started at that time. Well,
if TWC didn't update their PTR records then Comcast would reject
connections to TWC. Even after making updates to PTR records in one's
own nameserver after a change, it still takes time to propagate those
changes through the chaining of DNS servers. Could take 4 to 24 hours,
or longer, depending on the TTL for an entry in the DNS cache, to reach
the DNS server you use or the one your sending e-mail provider uses for
that DNS server to expire old entries. The TTL could be short, like 5
minutes, but the shorter the TTL then the more cache trashing there is.

TWC's MX servers have a TTL of 10 minutes. However, any record changes
in their nameserver still have to propagate through the chain of DNS
servers. 10 minutes through a series of DNS servers propagating the
change could be quite a while. Depends on how far up and down the
branches in a DNS tree for your or your e-mail provider DNS server.
Plus, if the poster was correct about TWC "moving" their servers, TWC
would likely need to update their PTR records. A move that didn't
entail an IP address change wouldn't be much of a logical move
experienced outside of the server hosts. With a move (that effected an
IP address change), someone at TWC would have to make the update, and
humans are fallible.

Without an exhibit of the actual NDR e-mailed to the OP, it is unclear
what part of the body of the NDR was from Comcast and what was the
encapsulated error message returned from TWC (if TWC even responded).
To me, and without knowing which part of the OP's chop-and-paste came
from what part of the body of the NDR, it seemed Comcast was reporting
that it refused connection to TWC. I can see how the limited info could
be interpreted the other way around. Comcast and Microsoft demand a
e-mail provider have a PTR record to validate that server is authorized
at the nameserver's domain. Looks like TWC has that requirement; see:

https://business.timewarnercable.com/support/resources/internet/dns/dns-records/how_to_create_a_ptrrecord.html

Seems the NDR the OP got was Comcast saying TWC's server did not have a
valid PTR record. It was TWC's servers that "moved" hence more likely
their PTR record has not been yet updated by them or it had not yet
propagated through the DNS chain. The OP reported the NDR that he got
on June 25 when he also opened his thread here. We don't know what the
NDR said when he could get his e-mail to his friend 3 weeks ago.

[Nil]

On 29 Jun 2018, Barry Margolin <bar...@alum.mit.edu> wrote in
alt.online-service.comcast:

> If you check the forum link I posted earlier, AUP#I-1000 is a TWC
> error code, not a Comcast error code. I think Comcast's servers
> use codes with 3 numbers separated by decimal points.

I think you're right about Comcast's codes. I sent an email from Gmail
to an intentionally bad Comcast address and it bounced back with error
code "5.1.1"

====================

Final-Recipient: rfc822; nvvnmfdj...@comcast.net
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx2.comcast.net. (2001:558:fe21:2a::6, the server for
the domain comcast.net.)
Diagnostic-Code: smtp; 550 5.1.1 Not our Customer
Last-Attempt-Date: Fri, 29 Jun 2018 17:14:29 -0700 (PDT)

[Barry Margolin]

In article <i6c3qiia35w6$.dlg@v.nguard.lh>, VanguardLH <V...@nguard.LH>

That's right. It's probably just a generic message that goes with the
"554" status code. It would probably be more correct for it to be worded
"service not available" -- it's denying service to the client because of
an AUP restriction.

>
> > If you check the forum link I posted earlier, AUP#I-1000 is a TWC error
> > code, not a Comcast error code. I think Comcast's servers use codes with
> > 3 numbers separated by decimal points.
>
> I linked to that same forum thread 10 hours before you in another
> subthread. That poster was trying to use a private SMTP server which
> would likely not have a PTR record in TWC's nameserver hence why that
> poster had problems with TWC accepting his private SMTP as a sending
> MTA. TWC was treating this private SMTP sending server similar to how
> Comcast or Microsoft or many others would treat the TWC receiving SMTP
> servers that didn't have a valid PTR record.

And in this case, for some reason TWC has the Comcast server on the same
block list.

>
> One poster there noted the TWC servers were getting "moved" (but unclear
> what that entailed) and problems with *TWC* started at that time. Well,
> if TWC didn't update their PTR records then Comcast would reject
> connections to TWC. Even after making updates to PTR records in one's
> own nameserver after a change, it still takes time to propagate those
> changes through the chaining of DNS servers. Could take 4 to 24 hours,
> or longer, depending on the TTL for an entry in the DNS cache, to reach
> the DNS server you use or the one your sending e-mail provider uses for
> that DNS server to expire old entries. The TTL could be short, like 5
> minutes, but the shorter the TTL then the more cache trashing there is.

You still seem to be treating this as Comcast rejecting the TWC server
when it's clear to me that TWC is rejecting the Comcast server.

If Comcast couldn't connect to the TWC server, it would just queue the
message and keep retrying periodically.

>
> TWC's MX servers have a TTL of 10 minutes. However, any record changes
> in their nameserver still have to propagate through the chain of DNS
> servers. 10 minutes through a series of DNS servers propagating the
> change could be quite a while.

DNS changes don't normally propagate like that, unless you have a
hierarchy of servers using the "forwarders" mechanism, which is unlikely
for an ISP. The caching servers query authoritative servers directly, so
they expire records as soon as the TTL expires.