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

[Narcis Garcia]

DKIM could be a good solution between servers but never implying neither
forwarding nor client software.
SPF is enough to solve the problems DKIM tries to, and SPF does not
complicate everybody's life.

PGP signatures and encryption is a much better solution for users, and
leaves DKIM with no sense.

I prefer second mentioned solution (to deal with SPF if necessary),
keeping subject prefix (this makes life easier to users) and keeping
message footer (this makes life easier to unexperienced users).

DMARC has nothing to do with this issue, because DMARC supports SPF.


El 24/10/19 a les 22:15, address@hidden ha escrit:
> 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
>