> Most of the junk we've been getting passes DMARC and has an unsubscribe link.

You say that like its a problem.. its a formidable solution!

Has worked for me for many years now: Just fail2ban-style block (groups of) relays that attempt to send an unsubscribe-link destined for a mailbox that never ever subscribes to anything. Those malicious-compliance folks add these unsubscribe links everywhere because they determined that its a cheap method for reducing blocks. That makes them reliably stand out whenever they hit strictly human-to-human mailboxes that simply never have any reason to "unsubscribe". Its like a honeypot, and all it took was a strict policy about what a tiny fraction of mailboxes can and cannot be used for.

▲

adiabatichottub an hour ago | parent [-]

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.

	▲	edelbitter 31 minutes ago \| parent [-]
		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.