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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
