In theory, if I have a receiver that has maxInboundMessageSize set to 4MB, and a sender that has maxOutboundMessageSize set to 4MB, the sender should always fail fast, and the receiver should never fail due to the inbound message exceeding it's receive size.

However, this isn't true, in cases where compression is used. Compression does not always result in smaller payloads, compression can increase the size of a payload, particularly when compressing random data. Since the MessageFramer does not currently check the actual length of the payload against maxOutboundMessageSize, a sender that is configured to mirror a receivers max sending size can still send a message that is too large for the receiver to receive, which would be quite surprising behaviour for anyone that encountered it.

Although the likelihood of this happening is low, I think for correctness sake, and because it would be trivial to introduce the check, the payload should also be checked against maxOutboundMessageSize, in addition to the uncompressed message data.