Not a lot.

#1 is to improve your spam filtering.   I have implemented Declude, with a lot of customization to make it database driven, and have dramatically improved my spam filtering capabilities over what I was able to obtain using commercial products.   Declude basically does all my sender-based filtering.   Anything that it does not reject is passed to my two commercial products, which are better at content filtering.

#2 (if applicable) is to control who is allowed to forward.   I suggest that the necessary protocol for forwarding is: (a) the source user requests a forward, 

(b) the source domain assesses whether the forwarding should be allowed based on the user making the request and the organizations data-loss-prevention policies.

(c) the source domain system administrator requests an email from the target user to confirm that the forward is desired (and that the forwarding address is not mis-spelled, maliciously targeted, etc.)

(c) if possible, the source domain system administrator contacts the target domain system administrator to notify them of the forwarding scenario.

(d) If no roadblocks are identified at steps b through d, the forward is allowed.

If you are an email hosting service, item (b) may not be an issue for you, but it might be an issue for your client domain administrator.

Currently, there is no standards-based method for implementing this protocol.    If you want to join the IETF DMARC working group, you can lobby for my proposal (ticket #79) if and when the group gets to this item

I think you might be able to implement a version of this protocol using two copies of Declude, one as your incoming gateway and one as the outgoing gateway, but it would require quite a bit of custom code.  The incoming gateway would need to log the TO address as a message header.  Then, the outgoing gateway would need to check the previous TO address and the new TO address against a database of allowed forwards.   I have not attempted to build this solution because we have disabled all auto-forwarding by organization policy.

Edit:   I think Declude only provides visibility to the To header, not the SMTP Recipient list.     The idea still stands, but some other product(s) would need to do the tag insertion upon domain entry and tag parsing upon domain exit.