Strict rp-filter - is this a bug?

Consider this network topology:
Untitled.png
CHR1 and CHR3 have default GW of CHR2. CHR2 has nothing but locally-connected routes (no default GW)

I set CHR2 to use rp-filter=strict

Then CHR1 has a srcnat rule to do some packet spoofing if the destination address is 10.2.3.3, and non-spoofed if the destination is 10.2.3.4

I did a packet sniffer capture on CHR-2 and discovered the following:

If I ping 10.2.3.4 from 10.1.2.1 (non-spoofed) then the ping works properly.

3.3.3.3 is an auxiliary “out on the Internet somewhere” address for CHR-1 - CHR-2 doesn’t have a route to it, so it should be dropped by rp-filter.
If I send a ping to 10.2.3.4 from source=3.3.3.3, then CHR-2 drops the packet as expected.

Unexpected result:
If I send a spoofed ping to 10.2.3.3 from CHR-1 with the source address=10.2.3.2, then CHR-2 actually forwards the spoofed ping to CHR-3, which replies to 10.2.3.2 where it gets dropped.

Shouldn’t strict rp-filter also drop this?

EDIT: I also just tested and confirmed that CHR2 will also forward spoofed packets if the spoofed source is 10.1.2.2 - I assume this extends to mean that any spoofed source which is an IP configured on the Mikrotik itself will be forwarded even if rp-filter=strict.

The goal of my lab was actually to test whether rp-filter=strict would prevent the DNS proxy from replying to spoofed-source packets on the LAN (if the filter only checks in-interface, but the source is spoofed, it would be bad for replies to be sent to the spoofed source). I’m happy to report that the dns proxy seems to ignore spoofed-source queries even if rp-filter is set to no…