I am afraid we need to clarify a confusion about the RD, RT, and their purpose so we dont step on our toes.
The RD is configured under the VRF and is appended to the NLRI. The purpose of RD is only to help BGP distinguish between the same-looking networks from different VRFs - for instance: a BGP advertisement about 192.168.1.0/24 in VRF B does not look like a BGP update of 192.168.1.0/24 in VRF A.
This is where the task of RD ends. It is not used as a tool to decide what VRF can a route be imported to or exported from.
On the other hand, a Route Target is an extended community attribute that can be attached multiple times to a route and it allows control of the VPN membership. With them you manage which prefixes get advertised between VRFs and how your VPN topology would be (i.e. hub and spoke, full mesh). Their actions can be defined as follows:
Import: allow routes from the MPLS core to get into the VRF
Export: allow routes from the VRF to get out of the VRF to the MPLS core.
These operations are not dependent of an specific RD, they only depend on the RTs and the import/export actions.
There is a way to advertise your routes selectively (via a route map, tagging the prefixes with the extended community and removing the export statement in the VRF), but that would affect both VRFs importing them.
Now, on the Quagga side that you mentioned yourself you cannot configure, there are two distinct VRFs, both interested in the same set of routes since both use the same "route-target import". The moment you set that RT in a "route-target export" command, both VRFs on the Quagga side will receive those routes. There is no way you can make it more selective on the sender side, and RD will not help here because the Quagga is not use the RD for any route sorting or filtering purposes - in fact, no router would since this is not how BGP sorts routes into VRFs.
Sorry to disappoint, but in this case, there is no solution without cooperating with the Quagga administrators, and changing the RTs so that the two VRFs on the Quagga side potentially have a subset of non-overlapping RTs.
Please note that BGP as a protocol is still based on the mutual trust paradigm; if an administrator maliciously misconfigured his BGP to import routes into VRFs they should not be in, there is hardly anything you can do about it, apart from not advertising those routes to that router at all.