[FFmpeg-devel] Patchwork attribution

[Michael Niedermayer]

On Thu, Apr 18, 2019 at 03:03:44PM -0400, Lou Logan wrote:
> On Thu, Apr 18, 2019, at 4:51 AM, Hendrik Leppkes wrote:
> >
> > Whoever setup this ML sender rewriting thing should probably look into
> > options to also re-write the patch content and add a "From:" line in
> > there with the original name and email to avoid issues.
> 
> I enabled this due DMARC as Timo correctly pointed out. This was due to the seemingly increasing number of rejected/bounced messages from certain domains resulting in the recipient being automatically unsubscribed from the list. I changed this relatively recently (last month?). I was unaware of the patchwork issue.
> 
> This was implemented with the "dmarc_moderation_action" option within Mailman. It is currently set to "Munge from" and was previously set to "Accept". More info:
> 
> https://wiki.list.org/DEV/DMARC
> 

> There is no perfect solution to the DMARC situation as far as I know.

There may be, but not trivial
0. Understand the problem
-> This appears that DMARC ignored the mailing list use case
1. decide&agree on a way to do mailing lists in DMARC
2. get the RFCs updated
3. get the implementations updated

OR
1. decide&agree on a way to do mailing lists around DMARC
2. write a spec
3. update relevant implementations to follow this spec

For example, one way that would mitigate the issue would be to
A. include the original "FROM:" in a new header or something (patch in mailman)
B. have the receiving side detect subscribed mailing lists do a maxumum of
   validity checks and undo the FROM change (patch in git, patchwork, MUAs or
   some other component that can undo the mess)
   
Iam sure there are issues and its more complex than this, but i dont think
it has to be as bad as it is currently if theres some crazy volunteer.

PS: also i did not look into existing efforts to resolve this, so quite
likely others have spend much more time on this and have found more
thought through redesigns ... I primarly just think that there is
some way that is better than what has to be done currently ...

Thanks

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190418/50775db9/attachment.sig>