Quoting Mark Trickett via luv-talk (luv-talk@luv.asn.au):
I would ask whether there are other ways of verifying that the incoming contributions are legitimate, not spoofed sender spam.
That is not the problem space. LUV's mailing list server is able to check DKIM/DMARC or SPF records to validate that the IP source matches published data in the incoming mail's claimed sending domain's DNS saying 'trust these IPs as authorised senders for this domain'. That works just fine. However, when the mail is relayed through Mailman and redirected out to subscribers' own SMTP hosts, those SMTP hosts will tend to fail the mail on the same tests that it passed on the initial transmission, because a new IP -- LUV's IP -- is now purporting to _also_ be an authorised sender IP for the sender's domain (even though LUV's IP _isn't_ listed in the sending domain's DKIM/DMARC or SPF DNS records). Russell's solution amounts to 'change the sender upon retransmission to the subscribers'. That solution runs headlong into those of us who consider having our correct 'From: ' information included in our SMTP headers to be a feature rather than a bug, e.g., it has even _worse_ effects than do the infamously wrong-headed idea of 'Reply-To munging' on the intended existence of reply-sender alongside reply-all response modes. Like Reply-To munging on steroids, the current solution makes reply-sender not work at all, and also conceals the sender's contact e-mail address entirely. Which is pretty serious collateral damage, which should IMO not be taken lightly. Making the retransmitted mail still pass DKIM/DMARC creates more damage and is even more of a problem than just making it pass SPF, because DKIM/DMARC tests the internal 'From: ' SMTP header while SPF does not. (Thus, Russell feels compelled to rewrite the 'From: ' header and substitute a -- pardon the expression -- forged sender of 'luv-talk@luv.asn.au' with GECOS field '[firstname] [lastname] via luv-talk'.)
I am not asking you to spend a lot of time and effort, but to all the contributors to this to try to make positive suggestions as to what might be possible, even if not currently implemented in the available software.
Unfortunately, if Russell wants traffic transiting through LUV's servers to always be able to continue to pass DKIM/DMARC even after retransmission, he'll need to rewrite the transmitted copies pretty much the way he's doing it. The trivial detail of the ' via luv-talk' suffix on the GECOS field can be fixed easily enough by just finding the *.py file that does that and editing it. However, that's cosmetic. E.g., it's slightly less bad if my SMTP headers get forged to say 'From: Rick Moen <luv-talk@luv.asn.au>' instead of 'From: Rick Moen via luv-talk <luv-talk@luv.asn.au>' -- but that GECOS suffix isn't the real problem numerous of us have raised. It's that it's _supposed_ to continue to say 'From: Rick Moen <rick@linuxmafia.com>', the way I sent it, without intermediate software interfering and purporting to change who sent the mail or from where. Ultimately, LUV either messes with user's mail contents in a fashion that conceals and falsifies the original 'From: ' information the sender specified, with additional damage of sabotaging reply-sender operations, or it doesn't. I appreciate what Russell is trying to do, and would not dream of impugning his good intentions, but would rather he not make LUV's server rewrite my (for one) mail in this way. The specific reason I question the necessity is that I'm not seeing all the other mailing lists being driven to this measure. Indeed, I'm not seeing that elsewhere at all, including on the numerous technical mailing lists *I* administer in the San Francisco Bay Area. Once again, I have the highest of respect for what Russell is trying to pull off. I just don't think the side-effects are justifiable. -- Cheers, <BombScare> i beat the internet Rick Moen <BombScare> the end guy is hard rick@linuxmafia.com -- seen on IRC McQ! (4x80)