Does this policy violate antispam laws that require mailing list messages to contain instructions how to be taken off the list?
-- hendrik On Thu, Oct 24, 2019 at 04:18:39PM -0400, [email protected] wrote: > The Free Software Foundation has changed the GNU Mailman settings on > this list. The short version is that any subject prefix or message > footer has been removed, allowing us to turn off DMARC from munging. > Any list administrator for this list is free to change these settings > back, instructions are below. > > The change is to better deal with increased adoption of the DMARC email > standard. The default Mailman settings were causing messages sent from > users with strict DMARC policy domains like yahoo.com to be rejected > when sent to list subscribers by Mailman. See the end of this email for > a technical overview of DMARC and DKIM. There are two main ways to fix > the issue by changing Mailman list settings. > > The first option, and the preferable way for discussion lists, is what > we call the "unmodified message fix." There are Mailman list settings > which modify the messages by adding a subject prefix (e.g. [list-name]) > or a footer. Modifying the message breaks DKIM message signatures and > thus DMARC, so we just turn those off. Many lists are already this way > and there is no change for them. Instead of using the subject prefix to > identify a list, subscribers should use the List-Id, To, and Cc headers. > List footer information can also be be put in the welcome email to > subscribers and the list information page by list administrators. > > We changed the default for new lists to send unmodified messages, and > are now updating existing discussion lists to the new default. We > emailed all list administrators and moderators and Savannah group admins > to allow them to opt in to the alternate fix before we made this > change. However, not all lists had a valid administrator contact. > > The second option is for lists which want or need to continue to modify > the message, for example with subject prefix or footer settings. In this > case we turn on a Mailman list setting called dmarc_moderation_action: > "Munge From". With this, if a strict DMARC sender sends to the list, we > alter the headers of that message like so: > > A message sent to the list: > > From: Anne Example Person <exampleperson@examplepersonsdomain> > > Is modified by Mailman and sent to subscribers as: > > From: Anne Example Person via Alist <alist@listdomain> > Reply-To: Anne Example Person <exampleperson@examplepersonsdomain> > > Without going into all of the details, here's a few points about why we > concluded the unmodified message fix is better for discussion > lists. Email clients don't all treat munged messages the same way as > unmunged, and humans read these headers so it can confuse people, > causing messages not to be sent to the expected recipients. GNU Mailman > has an option to do "Munge From" always, but does not recommend using > it[1]. While we're not bound by what others do, it's worth noting that > other very large free software communities like Debian GNU/Linux have > adopted the unmodified message fix[2]. The unmodified messages fix > avoids breaking DKIM cryptographic signatures, which show the message > was authorized by the signing domain and seems like a generally good > security practice. Tools to manage patches, for example patchew, use the > from field and are tripped up by from munging. > > For any Mailman list administrator who wants to change or look over the > relevant settings: The dmarc_moderation_action setting is under "Privacy > Options" subsection "Sender Filters". The only options that should be > selected are "Accept" or "Munge From", along with corresponding changes > to the subject_prefix option under "General Options", and msg_footer is > under "Non-digest options". > > If no list administrators or moderators are around for this list, anyone > should feel free to try to track them down or figure out who should > become one and explain in detail by replying to [email protected]. Please > be patient, this process may take several weeks. > > Please send any questions that should be public to [email protected]. For > private ones, just reply to [email protected]. > > For the general announcement of these changes, please read > https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html > and > https://lists.gnu.org/archive/html/savannah-hackers-public/2019-09/msg00016.html > > > A short DMARC technical overview: > > DMARC policy is a DNS txt record at a _dmarc subdomain. For example: > > $ host -t txt _dmarc.yahoo.com > _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; > rua=mailto:address@hidden;";; > > The only important thing there for our purpose is p=reject. p=reject > means that conforming mail servers that receive mail with a from header > of *@yahoo.com will reject that email unless it was either 1. sent from > Yahoo's email servers, or 2. its DKIM signature is verified. A DKIM > signature[5] is a public key cryptographic signature of the email body > and some headers included in the message header "DKIM-Signature". A > verified DKIM signature means that email body and signed headers have > not been modified. > > Comprehensive resources about DMARC tend to downplay or ignore its > problems, but some that have helped me are Wikipedia[6], the Mailman > wiki[1], dmarc.org wiki[7], and the DMARC rfc[8]. > > > > [1]: https://wiki.list.org/DEV/DMARC > [2]: https://lists.debian.org/debian-devel-announce/2015/08/msg00003.html > [5]: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail > [6]: https://en.wikipedia.org/wiki/DMARC > [7]: https://dmarc.org/wiki/FAQ#senders > [8]: https://tools.ietf.org/html/rfc7489 > > Ian Kelling | Senior Systems Administrator, Free Software Foundation > GPG Key: B125 F60B 7B28 7FF6 A2B7 DF8F 170A F0E2 9542 95DF > https://fsf.org | https://gnu.org >
