On 3/20/21 1:22 PM, mailman3@digicrime.com wrote:
I believe that your patch was for the web front end, but that would still allow people to join by sending email to listname-join@example.com. We wouldn't be running any web interface anyway. I wanted to disable all methods of users joining and only rely upon an administrative process to handle who joins. It's easy to imagine a corporate use case for this, such as "all people with offices in building 43" or "all employees with dependents on health insurance" where the definition of who is on a list is maintained in an external system. We're not actually a corporation - we're a professional society with different member classes in our membership database. In any case, the decision of who belongs on a list is not made by the user.
I understand these scenarios, but unless there is a high volume of spurious subscriptions, can't this be handled by setting the subscription police to include moderator approval?
In the interim I discovered another problem with DMARC failures in gmail when mail is sent through mailman3. Mail sent directly from our exim instance doesn't have this problem, so perhaps it's a problem with SRS. I won't be investigating this further, but I'm sure that SPF hard fails will be causing more problems for mailing lists in the future.
SPF always fails DMARC alignment on forwarded mail, whether from a mailing list or other forwarding mechanism because even though SPF may pass, the domain is that of the forwarding server, not the original sender.
While it is possible for a domain to set a DMARC policy and to rely only on SPF for validation, any domain with a DMARC policy should also be DKIM signing the mail because DKIM signatures will survive simple forwarding such as via .forward files or MTA aliases.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan