The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
--- Begin Message ---
Hi all:
I am trying to contribute a few trivial changes to OpenWrt. So far it has been frustrating. I recently jumped through all the hoops and managed to
e-mail the patches correctly (or so I believe):
http://lists.infradead.org/pipermail/openwrt-devel/2020-June/023887.html
http://lists.infradead.org/pipermail/openwrt-devel/2020-June/023888.html
However, when I look at Patchwork, it has picked up the following lines as part
of the commit message:
------------8<------------8<------------
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
------------8<------------8<------------
I am sure you have seen that often in this mailing list.
The Patchwork links where you can see that effect are:
https://patchwork.ozlabs.org/project/openwrt/patch/[email protected]/
https://patchwork.ozlabs.org/project/openwrt/patch/[email protected]/
I am not mailing list expert, but I have seen this problem recently with Microsoft Office 365 and with many other open-source-based mailing lists. It
has been talked about everywhere because many e-mail providers have been tightening e-mail policies in an uphill battle against spam.
I am using Yahoo, which I am not particular proud of, but this is a general issue affecting other providers. Under Patchwork, I could quickly find a
few other people who got those lines in their commit messages too.
Microsoft had to change the way their online system handles mailing list
e-mails, and many other people had to change their ways too.
From what I gathered, I believe it is reasonable for providers to demand that you shall not forge e-mails (send e-mails pretending to be the user).
And that is what many mailing lists actually tried to do until recently.
Could you please stop your mailing list server from adding that "The sender domain has a DMARC..." warning? The server should do whatever wrapping /
"reply to" header / forwarding it needs to do, or it has been decided it is best to do, and stop warning about it.
Some mailing list systems, like the OpenWrt forum, have no such issues when
forwarding e-mails.
I will also take this opportunity to mention again that Gerrit, while also somewhat annoying, provides a better user experience than Patchwork (in my
opinion). You can upload your patch directly from Git without facing e-mail formatting issues, and it tells you whether your patch compiles, and even
whether it conflicts with another patch (and which one). You can also comment directly on a patch. You can see it in action here:
http://openocd.zylin.com
I do not particularly advocate for Gerrit, as it has annoying usability issues
too, but it is a reminder that patch management can be better.
Patchwork does not seem able to pick up a patch from an e-mail attachment aptly named xxx.patch, and with an e-mail title that starts with [PATCH]. Or
maybe it is the mailing list server making it difficult. This is an example:
http://lists.infradead.org/pipermail/openwrt-devel/2020-June/023772.html
The attachment was dropped with the notice "A non-text attachment was scrubbed...", even though it is all plain text (all byte values are < 127).
Maybe the mailing list server just needs to learn that ".patch" is a common file extension used in development mailing lists.
You may of course insist on making people jump through your hoops in order to contribute. Such hoops are for example changing e-mail provider, having
to use "git send-email" because it is the only practical way to get it to work. Or having to write the first character in the commit line in
lowercase, and remembering to remove the period at the end.
Those procedures probably makes the maintainer's lives easier. It is like filling long, difficult forms when dealing with government bureaucracy: it
makes the lives of the public servants easier. But we all find that very annoying.
But my guess is that keeping such policies will damage the project in the long run. I have already noticed many small issues in the build system that
I have not bothered to send a patch for in the last years because of the high barrier of entry.
Ease of use is extremely important for most humans, more than one would reasonably assume. I personally can understand why people buy Apple or use
Visual Studio Code, which is a newcomer that has become very popular very fast. Such software is just easier to use than the alternatives.
I can also understand that you may not have the resources to change your ways. I just felt that these usability issues are worth stating clearly
(maybe once more).
Regards,
rdiez
--- End Message ---
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
