I'll have to ponder the method you describe. I know I could implement that on my own mailboxes and some automated endpoints, but not sure how that would work for other users on our domain.
Your suitable mailboxes will be very distinguishable by grepping for past triggers per original/unexpanded recipient. Most older destinations would have thousands of non-spam hits, the suitable ones will have 0-3 with an obvious quick fix. For me it was department-level to-whom-it-may-concern aliases: All the mailing lists and web service signups use the appropriate department/employee name, yet much of the incoming mail sent by humans - and: much of the mailing-list-impostors - comes through one of the aliases that merely clarify the topic/location but end up in the same boxes anyway.
Your suitable mailboxes will be very distinguishable by grepping for past triggers per original/unexpanded recipient. Most older destinations would have thousands of non-spam hits, the suitable ones will have 0-3 with an obvious quick fix. For me it was department-level to-whom-it-may-concern aliases: All the mailing lists and web service signups use the appropriate department/employee name, yet much of the incoming mail sent by humans - and: much of the mailing-list-impostors - comes through one of the aliases that merely clarify the topic/location but end up in the same boxes anyway.