Good question. I would say definitely not, since there is still the List-Unsubscribe: header, for example on this list it is
List-Unsubscribe: <https://lists.gnu.org/mailman/options/mailman>, <mailto:mailman-requ...@gnu.org?subject=unsubscribe> Many mail clients have a helpful interface to utilize that information. Hendrik Boom <hend...@topoi.pooq.com> writes: > 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, sysad...@gnu.org 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 sysad...@gnu.org. Please >> be patient, this process may take several weeks. >> >> Please send any questions that should be public to mail...@gnu.org. For >> private ones, just reply to sysad...@gnu.org. >> >> 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 >>