On Thu, Apr 23, 2020 at 10:47:18AM -0700, William Herrin wrote:
One of the annoyances with both those guys and the swedish folks is that they're not sending messages to the return path, they're responding to the header from address. Mailman at NANOG never sees it. It doesn't pass through their servers.
Yeah, I know: I've seen similar things on the Mailman-powered mailing lists that I've run.
Even if mailman saw it, mailman doesn't use VERP. It has to scan the message to match the subscriber and that doesn't consistently work. The subscriber address forwards to another address, the second address bounces and the bounce message doesn't necessarily contain the original subscriber address.
To identify these jokers the ops will probably have to send a unique message to each subscriber with crafted headers. That can be folded in to a message that would go to the list anyway but the capability isn't baked in to mailman.
I get all this, but there are other methods that should help narrow it down. For example (and I really do mean "example", this might or might not be useful in this case): one of the things I've done is to (1) grab the subscriber list (2) reduce it to domains (3) look up the MXs for every domain -- via a script (4) sort/uniq (5) see if any match the domain that appears to be the culprit. (Sometimes works.) Another approach is to look up the MX's for the culprit and see if those match any on the just-generated list. (Usually doesn't work.) Still another is to map the MX list to IP addresses, sort by address, then grab the IP addresses relevant to the culprit (from A, NS, MX) and see if those are local to any of the ones on the list. (Sometimes works.) All of these are hit-or-miss but I've found that pursuing them usually results in some insight, if not an answer. If nothing else it often allows the "exoneration" of some number of subscriber addresses, which reduces the scope of the problem and may render it tractable via other methods. But to your point, VERP or an equivalent tactic may be the only way to really diagnose/repair some of these. ---rsk