monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ian Kelling
Subject: Re: Fyi: this list, monotone-devel, just had it's subject [tag] and footer removed
Date: Thu, 31 Oct 2019 11:21:45 -0400
User-agent: mu4e 1.1.0; emacs 27.0.50

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:address@hidden?subject=unsubscribe>

Many mail clients have a helpful interface to utilize that
information.

Hendrik Boom <address@hidden> 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, 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
>> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]