I have a brother who lives in Frankfurt, Germany and when he sends me an e-mail it goes back to him as undeliverable. This has never happened before. Please help.
If he is using German based email server that ends in the top level domain ".de", such as " firstname.lastname@example.org ", then the email is being bounced for security reasons.
This problem would go away if you personally used a different worldwide email service provider, such as Google's Gmail.com, Microsoft's Outlook.com, AT&T's Yahoo.com, or other 'real' email systems. It's frustrating that Spectrum hasn't even found a way to deliver emails originating from smart phones roaming in Europe.
This sounds very similar to a problem I had beginning Dec 2018 with Spectrum blocking email from <t-online.de> (Deutsche Telekom, largest ISP in Europe) and <gmx.de>. If the sender receives an error message of the form:
then it is the same. It seems that only the 2 Spectrum receiving servers <dnvrco-cmedge01.email.rr.com> and <dnvrco-cmedge02.email.rr.com> block emails from those German ISPs. All the other 69 Spectrum servers allow those emails, as they have for 20 years. I determined that the 2 "cmedge" servers were originally registered to Charter Communications and the other 69 were Time Warner Cable. It appeared to me to be an integration problem merging the 2 server farms. Many, many phone calls to customer support over 2 months were futile - sometimes I was told all servers are TWC, sometimes I was told they are indeed different, managed by 2 separate groups, sometime told no emails are being blocked, sometimes told they are blocked as coming from known spam sites - it depended on who was on duty and you are dealing with the lowest level of support personnel who really know nothing. I asked how they identified Deutsched Telekom as a spam site and was told it was proprietary information.
I finally gave up and filed a complaint with the FCC, which required Spectrum to reply. I got the corporate non-answer: "we block spam sites." I responded to the FCC with all my data and asked for a more detailed response. The very next day I got a personal phone call from a technical support manager in NY who was very helpful and spent about an hour answering my questions directly. Yes, those servers are different, and probably (he didn't have details) used different criteria for filtering emails. They use commercially available spam blacklist sites, and he directed me to http://www.spamhaus.org/. Using the IP of my sister sending from <t-online.de> he pointed out that it is a non-static IP assigned by DT when she logs on, and is found in a PBL (Policy Black List) at https://www.spamhaus.org/pbl/. Read the description of PBL at that URL - these IPs may be subject to additional scrutiny by receiving servers since they often can be used by spammers if not properly authenticated by the sending server. Again, he didn't know the details, but I looked very carefully at the expanded headers of email coming from my sister at <t-online.de> and bro-in-law at <gmx.de> and saw that they did not contain any indication of authentication, either by the existence of a "DKIM-Signature" or other authentication field. Virtually every other email I get from any other sender in the U.S. has one of those fields.
I relayed all this to my German relatives and asked them to check with their ISPs about authentication. The <gmx.de> emails now have the DKIM-Signature field, but I have not received any email from him for months, nor has he reported any failures. My sister messed around with turning on SMTP authentication in her Apple Mail program, but her emails still appear to me to be unauthenticated. She was too busy and frustrated to deal any further with DT's postmaster and gave up - she uses Gmail to send to me.
Bottom line - If your brother gets the rejections only from "cmedge" servers, it may be the same problem. If you have older emails from him that succeeded you can check the headers to see if authentication is the issue. In that case do not expect any resolution by calling Spectrum customer support.
Caveat - some of the above analysis is speculation on my part, especially whether lack of authentication is the real, or only issue. The technical manger gave me his phone # and invited me to call if I have more questions, but since my sister has a workaround I have dropped it for now.