Is rejecting email based on IP address in chain allowed?

A major ISP is rejecting email (bouncing with error 550) on the basis that an IP address in the transmission chain is on their 'blocklist'. Are they allowed to do this and still be IETF compliant?

All I can find is RFC 2821:

An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only

This indicates that systems must not reject email, though in a different scenario.

Can someone enlighten us?

Arguably RFC's are about keeping the internet working and interconnected where as spam is abuse.

That means that there is also no RFC or other standard that defines "this is spam" ; creating such a standard would imply that everything that is not "standards compliant spam" should not be blocked and must be delivered...

Thus the classification of what is spam and what is not, is arbitrary and completely up to the (system used by) the recipient.

Once an email message has been identified as spam the recipient has roughly three choices:

• accept the spam - but don't deliver the message directly to the recipients INBOX, quarantine the message, label it and/or deliver it to a Spam folder.
• accept the spam and silently discard - arguably this violates the historical SMTP concepts and standards, the sender receives no notification that their message has not been delivered and the intended receiver remains unaware that somebody tried to reach them. See RFC 5321 - §6.2 as to when this can be allowed.
• reject the spam - although you want to avoid backscatter properly rejecting the message will result in a non-delivery error message to the sender (important in case of false positives)

The correct, standards compliant method, to refuse unwanted email is, when the sending mail server is still connected and during the SMTP transaction, to respond with a SMTP error. That can for example be an error from the 400 range but also from the 500 range:

5yz   Permanent Negative Completion reply
  The command was not accepted and the requested action did not
  occur.  The SMTP client is discouraged from repeating the exact
  request (in the same sequence).  Even some "permanent" error
  conditions can be corrected, so the human user may want to direct
  the SMTP client to reinitiate the command sequence by direct
  action at some point in the future (e.g., after the spelling has
  been changed, or the user has altered the account status).

RFC 2821 - §4.2.3

  550 Requested action not taken: mailbox unavailable
     (e.g., mailbox not found, no access, or command rejected
     for policy reasons)

The sending mail server can then still report the problem to the real sender cleanly, without causing backscatter.