can't deliver to GMX mail.com domain - 554 with no reason code

[#1]

I  need to correspond with someone who uses one of the GMX mail.com domains whose MX records point to

C:\Users\me>dig -t mx redacted.com
; <<>> DiG 9.10-P2 <<>> -t mx redacted.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32263
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;redacted.com.                    IN      MX
;; ANSWER SECTION:
redacted.com.             86400   IN      MX      10 mx00.mail.com.
redacted.com.             86400   IN      MX      10 mx01.mail.com.
;; AUTHORITY SECTION:
redacted.com.             86400   IN      NS      pdns1.ultradns.net.
redacted.com.             86400   IN      NS      pdns2.ultradns.net.
redacted.com.             86400   IN      NS      pdns3.ultradns.org.
redacted.com.             86400   IN      NS      pdns4.ultradns.org.
redacted.com.             86400   IN      NS      pdns5.ultradns.info.
redacted.com.             86400   IN      NS      pdns6.ultradns.co.uk.
;; Query time: 46 msec
;; SERVER: 212.159.6.9#53(212.159.6.9)
;; WHEN: Tue Mar 29 21:53:36 GMT Daylight Time 2016
;; MSG SIZE  rcvd: 257

but it just gets bounced with

A message that you sent to the following recipient could not be
delivered due to a permanent error. ** The remote server 74.208.5.20
responded with: ** user@redacted.com 554:For explanation visit
http://postmaster.gmx.com/en/error-messages?ip=212.159.14.19&c=bip This
message was created automatically by mail delivery software on the
server avasout04.

The supplied GMX URL points to a page that does not specifically explain the 554 code, so I have no idea why the delivery has failed.
If I try to deliver a message to my correspondent from a non-Plusnet e-mail provider, the message is delivered just fine.
So is this a reputation-based issue ?

[#2]

There would normally be additional text after the 554 code which explains the error. Then the link to that information page to get a more detailed explanation. If you try sending the message again does it still fail?

[#3]

I've been having the same problem since last Thursday, 24/3/16. I've been sending mail to this address for years - literally - so why the sudden change?
Tried phone support - useless!
Gmail to the same address works fine.
What's going on?
(same problem to @yours.com and bounces back with the same reference to the gmx error codes so suspect that email address is using gmx somewhere along the line).

[#4]

I have the same problem from Plusnet with gmx.de and web.de as of last week
The telephone support guy promised support but gave the game away by mumbling that he was searching "online" for an answer..................
The promised email to confirm his "help ticket" never arrived.
I changed from Avast antivirus to AVG to see if that might help but it didn't.
This has become a terrible disappointment in what has been a good service.

[#5]

Quote from: spraxyt

There would normally be additional text after the 554 code which explains the error. Then the link to that information page to get a more detailed explanation. If you try sending the message again does it still fail?

Like I said - no actual reason given for the 554 and the referenced GMX help page only refers to 5xy, not 554.
I'm going to assume that

c=bip

is shorthand for 'code= blacklisted IP' unless anyone tells me otherwise.
Shame Plusnet don't have better processes for curating their SMTP server reputation - no excuse for poor sendability with an ISP - anyone caught spamming should have their mail accounts suspended for an appropriate first-strike period - 6 months, say, as the knock-on effects for everyone else when a server gets on one of the blacklists are highly disruptive.

[#6]

I checked the IP of the relay server used (avasout04) and it *didn't* appear on any of the spamhaus blacklists or policy blocklists, that the GMX policy document mentioned. If any of the Plusnet relay servers were blacklisted there would surely be a multitude of complaints here, for numerous email addresses, not just those going to GMX.addresses.

[#7]

update: the help ticket notification I was promised actually arrived this morning.... hopefully someone will act on it!

[#8]

Just successfully sent to @gmx.com sent through avasout07. Problem seems to be with avasout03 and avasout04, let's hope someone reading this can sort it out!

[#9]

Just called customer service on 0345 140 0200.
Took a while to get the guy to understand the problem, eventually checked my connection and noticed that my router had rebooted earlier in the day, which would have resulted in a new dynamic IP address and that's probably why the problem is solved for me.
Apparently, if an IP address is blocked at some time, for whatever reason, it remains blocked, so the next time someone else picks up that IP address it will block them! You'd think they could get it to drop the block as soon as that connection is lost.
So try rebooting your routers folks - oh and call plusnet so they know it's not an isolated incident.

[#10]

Oh dear oh dear oh dear - PN 'technical' support strikes again... 
The nonsense that you've been told would only be the case if you are running your own mail server on your connection.  The issue described is to do with the reputation of PN's outgoing mail servers and these have nothing to do with the reputation of your allocated IP address (other than it may *perhaps* determine which outgoing server your mail gets routed through).

[#11]

Quote from: spraxyt

I checked the IP of the relay server used (avasout04) and it *didn't* appear on any of the spamhaus blacklists or policy blocklists, that the GMX policy document mentioned. If any of the Plusnet relay servers were blacklisted there would surely be a multitude of complaints here, for numerous email addresses, not just those going to GMX.addresses.

So did I, and I got substantially the same result ( only blacklisted on the LASHBACK blacklist).
However, low-reputation mail servers are continually being added to and removed from the various blacklists on time-scales ranging from hours to days depending on how responsive the SMTP monitoring team is for any given massively shared server.
It's a forlorn game of whack-a-mole for the hapless operators of these tainted servers; if they had more aggressive SMTP abuse detection and really severe sanctions against obvious spammers, then this sort of thing would be a rarity rather than a commonplace.