Re: Fyi: this list, monotone-devel, just had it's subject [tag] and footer removed

[Hendrik Boom]

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, address@hidden 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 address@hidden. Please
> be patient, this process may take several weeks.
> 
> Please send any questions that should be public to address@hidden. For
> private ones, just reply to address@hidden.
> 
> 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
>