[alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]

[alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 316 bytes --]

Hi,

Here's another mail (one of several in this series) that got completely
mangled by the alsa-project.org mailman to the point of unusability.  I
didn't see any response to my last mail about this, is there any news on
fixing mailman to not do this?  It's extremely disruptive to working
with lore.

Thanks,
Mark

[-- Attachment #1.2: Type: message/rfc822, Size: 2169 bytes --]

From: AngeloGioacchino Del Regno via Alsa-devel <alsa-devel@alsa-project.org>
Subject: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe
Date: Wed, 03 May 2023 13:34:11 +0200
Message-ID: <168311377075.26.14919941665402646886@mailman-core.alsa-project.org>

Use devm_pm_runtime_enable() and pm_runtime_resume_and_get() to
to simplify the probe function.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
index 9e45efeada55..a54c16e0aa05 100644
--- a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
+++ b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
@@ -3179,16 +3179,16 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
 
 	mt8195_afe_parse_of(afe, pdev->dev.of_node);
 
-	pm_runtime_enable(dev);
-	if (!pm_runtime_enabled(dev)) {
-		ret = mt8195_afe_runtime_resume(dev);
-		if (ret)
-			return ret;
-	}
-
 	/* enable clock for regcache get default value from hw */
 	afe_priv->pm_runtime_bypass_reg_ctl = true;
-	pm_runtime_get_sync(dev);
+
+	ret = devm_pm_runtime_enable(dev);
+	if (ret)
+		return ret;
+
+	ret = pm_runtime_resume_and_get(dev);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to resume device\n");
 
 	afe->regmap = devm_regmap_init_mmio(&pdev->dev, afe->base_addr,
 					    &mt8195_afe_regmap_config);
@@ -3238,7 +3238,10 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
 
 	mt8195_afe_init_registers(afe);
 
-	pm_runtime_put_sync(dev);
+	ret = pm_runtime_put_sync(dev);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to suspend device\n");
+
 	afe_priv->pm_runtime_bypass_reg_ctl = false;
 
 	regcache_cache_only(afe->regmap, true);
@@ -3248,7 +3251,6 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
 
 err_pm_put:
 	pm_runtime_put_sync(dev);
-	pm_runtime_disable(dev);
 
 	return ret;
 }
-- 
2.40.1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]

[Takashi Iwai]

On Thu, 04 May 2023 03:09:45 +0200,
Mark Brown wrote:
> 
> Hi,
> 
> Here's another mail (one of several in this series) that got completely
> mangled by the alsa-project.org mailman to the point of unusability.  I
> didn't see any response to my last mail about this, is there any news on
> fixing mailman to not do this?  It's extremely disruptive to working
> with lore.

It seems that alsa-project.org mailman re-sends the post with
xxx@alsa-project.org address sometimes, indeed.  I don't know the
condition, but now I noticed it while checking the pending approvals.
Those that appeared in the list wrongly were likely the posts I
approved without knowing them being superfluously resent ones.

Jaroslav, could you check your mailman configuration?


thanks,

Takashi

> Thanks,
> Mark
> Subject: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe
> From: AngeloGioacchino Del Regno via Alsa-devel <alsa-devel@alsa-project.org>
> Date: Wed, 03 May 2023 13:34:11 +0200
> Message-Id: <168311377075.26.14919941665402646886@mailman-core.alsa-project.org>
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> 
> Use devm_pm_runtime_enable() and pm_runtime_resume_and_get() to
> to simplify the probe function.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 22 ++++++++++++----------
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> index 9e45efeada55..a54c16e0aa05 100644
> --- a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> +++ b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> @@ -3179,16 +3179,16 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
>  
>  	mt8195_afe_parse_of(afe, pdev->dev.of_node);
>  
> -	pm_runtime_enable(dev);
> -	if (!pm_runtime_enabled(dev)) {
> -		ret = mt8195_afe_runtime_resume(dev);
> -		if (ret)
> -			return ret;
> -	}
> -
>  	/* enable clock for regcache get default value from hw */
>  	afe_priv->pm_runtime_bypass_reg_ctl = true;
> -	pm_runtime_get_sync(dev);
> +
> +	ret = devm_pm_runtime_enable(dev);
> +	if (ret)
> +		return ret;
> +
> +	ret = pm_runtime_resume_and_get(dev);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to resume device\n");
>  
>  	afe->regmap = devm_regmap_init_mmio(&pdev->dev, afe->base_addr,
>  					    &mt8195_afe_regmap_config);
> @@ -3238,7 +3238,10 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
>  
>  	mt8195_afe_init_registers(afe);
>  
> -	pm_runtime_put_sync(dev);
> +	ret = pm_runtime_put_sync(dev);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to suspend device\n");
> +
>  	afe_priv->pm_runtime_bypass_reg_ctl = false;
>  
>  	regcache_cache_only(afe->regmap, true);
> @@ -3248,7 +3251,6 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
>  
>  err_pm_put:
>  	pm_runtime_put_sync(dev);
> -	pm_runtime_disable(dev);
>  
>  	return ret;
>  }
> -- 
> 2.40.1

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]

[Takashi Iwai]

On Thu, 04 May 2023 09:35:38 +0200,
Takashi Iwai wrote:
> 
> On Thu, 04 May 2023 03:09:45 +0200,
> Mark Brown wrote:
> > 
> > Hi,
> > 
> > Here's another mail (one of several in this series) that got completely
> > mangled by the alsa-project.org mailman to the point of unusability.  I
> > didn't see any response to my last mail about this, is there any news on
> > fixing mailman to not do this?  It's extremely disruptive to working
> > with lore.
> 
> It seems that alsa-project.org mailman re-sends the post with
> xxx@alsa-project.org address sometimes, indeed.  I don't know the
> condition, but now I noticed it while checking the pending approvals.

And, I guess it happens when a post comes from a non-subscriber.
(But not sure whether this happens always...)
It waits for approval, but also mangles the sender address and co.
This behavior is new after the mail server update.

> Those that appeared in the list wrongly were likely the posts I
> approved without knowing them being superfluously resent ones.
> 
> Jaroslav, could you check your mailman configuration?

So, please check the configuration.  As of now, the post from
non-subscriber becomes confusing and unusable for b4.


thanks,

Takashi

> 
> 
> thanks,
> 
> Takashi
> 
> > Thanks,
> > Mark
> > Subject: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe
> > From: AngeloGioacchino Del Regno via Alsa-devel <alsa-devel@alsa-project.org>
> > Date: Wed, 03 May 2023 13:34:11 +0200
> > Message-Id: <168311377075.26.14919941665402646886@mailman-core.alsa-project.org>
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > 
> > Use devm_pm_runtime_enable() and pm_runtime_resume_and_get() to
> > to simplify the probe function.
> > 
> > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > ---
> >  sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 22 ++++++++++++----------
> >  1 file changed, 12 insertions(+), 10 deletions(-)
> > 
> > diff --git a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> > index 9e45efeada55..a54c16e0aa05 100644
> > --- a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> > +++ b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> > @@ -3179,16 +3179,16 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
> >  
> >  	mt8195_afe_parse_of(afe, pdev->dev.of_node);
> >  
> > -	pm_runtime_enable(dev);
> > -	if (!pm_runtime_enabled(dev)) {
> > -		ret = mt8195_afe_runtime_resume(dev);
> > -		if (ret)
> > -			return ret;
> > -	}
> > -
> >  	/* enable clock for regcache get default value from hw */
> >  	afe_priv->pm_runtime_bypass_reg_ctl = true;
> > -	pm_runtime_get_sync(dev);
> > +
> > +	ret = devm_pm_runtime_enable(dev);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = pm_runtime_resume_and_get(dev);
> > +	if (ret)
> > +		return dev_err_probe(dev, ret, "Failed to resume device\n");
> >  
> >  	afe->regmap = devm_regmap_init_mmio(&pdev->dev, afe->base_addr,
> >  					    &mt8195_afe_regmap_config);
> > @@ -3238,7 +3238,10 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
> >  
> >  	mt8195_afe_init_registers(afe);
> >  
> > -	pm_runtime_put_sync(dev);
> > +	ret = pm_runtime_put_sync(dev);
> > +	if (ret)
> > +		return dev_err_probe(dev, ret, "Failed to suspend device\n");
> > +
> >  	afe_priv->pm_runtime_bypass_reg_ctl = false;
> >  
> >  	regcache_cache_only(afe->regmap, true);
> > @@ -3248,7 +3251,6 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
> >  
> >  err_pm_put:
> >  	pm_runtime_put_sync(dev);
> > -	pm_runtime_disable(dev);
> >  
> >  	return ret;
> >  }
> > -- 
> > 2.40.1

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]

[Takashi Iwai]

On Thu, 04 May 2023 09:58:44 +0200,
Takashi Iwai wrote:
> 
> On Thu, 04 May 2023 09:35:38 +0200,
> Takashi Iwai wrote:
> > 
> > On Thu, 04 May 2023 03:09:45 +0200,
> > Mark Brown wrote:
> > > 
> > > Hi,
> > > 
> > > Here's another mail (one of several in this series) that got completely
> > > mangled by the alsa-project.org mailman to the point of unusability.  I
> > > didn't see any response to my last mail about this, is there any news on
> > > fixing mailman to not do this?  It's extremely disruptive to working
> > > with lore.
> > 
> > It seems that alsa-project.org mailman re-sends the post with
> > xxx@alsa-project.org address sometimes, indeed.  I don't know the
> > condition, but now I noticed it while checking the pending approvals.
> 
> And, I guess it happens when a post comes from a non-subscriber.
> (But not sure whether this happens always...)
> It waits for approval, but also mangles the sender address and co.
> This behavior is new after the mail server update.

Jaroslav, could you investigate it?  I checked again, and it seems
that all "approved" posts from non-subscribers are modified to the
sender addresses with alsa-project.org.  I guess there must be some
option to prevent it.


Takashi

> > Those that appeared in the list wrongly were likely the posts I
> > approved without knowing them being superfluously resent ones.
> > 
> > Jaroslav, could you check your mailman configuration?
> 
> So, please check the configuration.  As of now, the post from
> non-subscriber becomes confusing and unusable for b4.
> 
> 
> thanks,
> 
> Takashi
> 
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > > Thanks,
> > > Mark
> > > Subject: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe
> > > From: AngeloGioacchino Del Regno via Alsa-devel <alsa-devel@alsa-project.org>
> > > Date: Wed, 03 May 2023 13:34:11 +0200
> > > Message-Id: <168311377075.26.14919941665402646886@mailman-core.alsa-project.org>
> > > MIME-Version: 1.0
> > > Content-Transfer-Encoding: 7bit
> > > 
> > > Use devm_pm_runtime_enable() and pm_runtime_resume_and_get() to
> > > to simplify the probe function.
> > > 
> > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > > ---
> > >  sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 22 ++++++++++++----------
> > >  1 file changed, 12 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> > > index 9e45efeada55..a54c16e0aa05 100644
> > > --- a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> > > +++ b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
> > > @@ -3179,16 +3179,16 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
> > >  
> > >  	mt8195_afe_parse_of(afe, pdev->dev.of_node);
> > >  
> > > -	pm_runtime_enable(dev);
> > > -	if (!pm_runtime_enabled(dev)) {
> > > -		ret = mt8195_afe_runtime_resume(dev);
> > > -		if (ret)
> > > -			return ret;
> > > -	}
> > > -
> > >  	/* enable clock for regcache get default value from hw */
> > >  	afe_priv->pm_runtime_bypass_reg_ctl = true;
> > > -	pm_runtime_get_sync(dev);
> > > +
> > > +	ret = devm_pm_runtime_enable(dev);
> > > +	if (ret)
> > > +		return ret;
> > > +
> > > +	ret = pm_runtime_resume_and_get(dev);
> > > +	if (ret)
> > > +		return dev_err_probe(dev, ret, "Failed to resume device\n");
> > >  
> > >  	afe->regmap = devm_regmap_init_mmio(&pdev->dev, afe->base_addr,
> > >  					    &mt8195_afe_regmap_config);
> > > @@ -3238,7 +3238,10 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
> > >  
> > >  	mt8195_afe_init_registers(afe);
> > >  
> > > -	pm_runtime_put_sync(dev);
> > > +	ret = pm_runtime_put_sync(dev);
> > > +	if (ret)
> > > +		return dev_err_probe(dev, ret, "Failed to suspend device\n");
> > > +
> > >  	afe_priv->pm_runtime_bypass_reg_ctl = false;
> > >  
> > >  	regcache_cache_only(afe->regmap, true);
> > > @@ -3248,7 +3251,6 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
> > >  
> > >  err_pm_put:
> > >  	pm_runtime_put_sync(dev);
> > > -	pm_runtime_disable(dev);
> > >  
> > >  	return ret;
> > >  }
> > > -- 
> > > 2.40.1

DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Jaroslav Kysela]

On 08. 05. 23 9:52, Takashi Iwai wrote:
> On Thu, 04 May 2023 09:58:44 +0200,
> Takashi Iwai wrote:
>>
>> On Thu, 04 May 2023 09:35:38 +0200,
>> Takashi Iwai wrote:
>>>
>>> On Thu, 04 May 2023 03:09:45 +0200,
>>> Mark Brown wrote:
>>>>
>>>> Hi,
>>>>
>>>> Here's another mail (one of several in this series) that got completely
>>>> mangled by the alsa-project.org mailman to the point of unusability.  I
>>>> didn't see any response to my last mail about this, is there any news on
>>>> fixing mailman to not do this?  It's extremely disruptive to working
>>>> with lore.
>>>
>>> It seems that alsa-project.org mailman re-sends the post with
>>> xxx@alsa-project.org address sometimes, indeed.  I don't know the
>>> condition, but now I noticed it while checking the pending approvals.
>>
>> And, I guess it happens when a post comes from a non-subscriber.
>> (But not sure whether this happens always...)
>> It waits for approval, but also mangles the sender address and co.
>> This behavior is new after the mail server update.
> 
> Jaroslav, could you investigate it?  I checked again, and it seems
> that all "approved" posts from non-subscribers are modified to the
> sender addresses with alsa-project.org.  I guess there must be some
> option to prevent it.

The answer is DMARC. And the "mangling" applies only to senders which domains 
have restricted DMARC settings (reject or quarantine) - collabora.com has 
quarantine. More information:

https://lore.kernel.org/alsa-devel/6f003598-4cae-a521-233f-2c19eb439359@perex.cz/

I am open to any suggestions, but the default mailman settings (do not do 
anything) causes that some (mostly gmail) users do not receive their e-mails 
because the ALSA's mail server has a bad reputation. Many companies are using 
the google mail service for their domains nowadays.

The information is not lost - the original e-mail is just encapsulated (as an 
attachmnent) to new with the "allowed from" header for DMARC. But yes, it 
requires some more work (reply to the attachment, update scripts).

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

On Tue, May 09, 2023 at 09:12:55AM +0200, Jaroslav Kysela wrote:
> On 08. 05. 23 9:52, Takashi Iwai wrote:

[alsa-devel rewriting mails in a way that renders them useless with b4]

> > Jaroslav, could you investigate it?  I checked again, and it seems
> > that all "approved" posts from non-subscribers are modified to the
> > sender addresses with alsa-project.org.  I guess there must be some
> > option to prevent it.

> The answer is DMARC. And the "mangling" applies only to senders which
> domains have restricted DMARC settings (reject or quarantine) -
> collabora.com has quarantine. More information:

> https://lore.kernel.org/alsa-devel/6f003598-4cae-a521-233f-2c19eb439359@perex.cz/

> I am open to any suggestions, but the default mailman settings (do not do
> anything) causes that some (mostly gmail) users do not receive their e-mails
> because the ALSA's mail server has a bad reputation. Many companies are
> using the google mail service for their domains nowadays.

> The information is not lost - the original e-mail is just encapsulated (as
> an attachmnent) to new with the "allowed from" header for DMARC. But yes, it
> requires some more work (reply to the attachment, update scripts).

Copying in Konstantin - as I said this is massively disruptive to using
b4 with anything that's been mangled, to the point where the messages
are unusable without substantial manual mangling (and signature
verification fails too).  It'd be more usable to just not have the
messages from the list getting to lore and manually bounce patches to
the list.  

Is it possible to take steps to improve the reptuation of the ALSA
servers so this isn't needed, or could we migrate the lists elsewhere (I
know we set up linux-sound@vger at one point with the idea of
migrating).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Jaroslav Kysela]

On 09. 05. 23 11:37, Mark Brown wrote:
> On Tue, May 09, 2023 at 09:12:55AM +0200, Jaroslav Kysela wrote:
>> On 08. 05. 23 9:52, Takashi Iwai wrote:
> 
> [alsa-devel rewriting mails in a way that renders them useless with b4]
> 
>>> Jaroslav, could you investigate it?  I checked again, and it seems
>>> that all "approved" posts from non-subscribers are modified to the
>>> sender addresses with alsa-project.org.  I guess there must be some
>>> option to prevent it.
> 
>> The answer is DMARC. And the "mangling" applies only to senders which
>> domains have restricted DMARC settings (reject or quarantine) -
>> collabora.com has quarantine. More information:
> 
>> https://lore.kernel.org/alsa-devel/6f003598-4cae-a521-233f-2c19eb439359@perex.cz/
> 
>> I am open to any suggestions, but the default mailman settings (do not do
>> anything) causes that some (mostly gmail) users do not receive their e-mails
>> because the ALSA's mail server has a bad reputation. Many companies are
>> using the google mail service for their domains nowadays.
> 
>> The information is not lost - the original e-mail is just encapsulated (as
>> an attachmnent) to new with the "allowed from" header for DMARC. But yes, it
>> requires some more work (reply to the attachment, update scripts).
> 
> Copying in Konstantin - as I said this is massively disruptive to using
> b4 with anything that's been mangled, to the point where the messages
> are unusable without substantial manual mangling (and signature
> verification fails too).  It'd be more usable to just not have the
> messages from the list getting to lore and manually bounce patches to
> the list.

The signature is correct in the encapsulated original e-mail. The b4 should be 
improved in my opinion.

For example, here is the original message:

https://lore.kernel.org/alsa-devel/168311377075.26.14919941665402646886@mailman-core.alsa-project.org/

As you see, the header and all signatures are correct in the attachment:

From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Authentication-Results: alsa1.perex.cz;
	dkim=pass (2048-bit key,
  unprotected) header.d=collabora.com header.i=@collabora.com
  header.a=rsa-sha256 header.s=mail header.b=HSzFx8Gb

> Is it possible to take steps to improve the reptuation of the ALSA
> servers so this isn't needed, or could we migrate the lists elsewhere (I

It is not possible to talk with gmail administrators. I tried that several 
times. The outgoing ALSA server is not on any spam list.

> know we set up linux-sound@vger at one point with the idea of
> migrating).

I guess that the vger servers have similar issues, because servers with DMARC 
enabled on the ingress side can reject e-mails. It's related to e-mail standards.

						Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]

On Tue, May 09, 2023 at 11:54:18AM +0200, Jaroslav Kysela wrote:

> The signature is correct in the encapsulated original e-mail. The b4 should
> be improved in my opinion.

It's not b4 that's the issue here except in that it causes me to fetch
copies of the message that went to the list instead of my inbox which
didn't get mangled by the list.  git am just does not understand what's
happening with attachments.  For example for:

   168198605952.26.13645408104113633580@mailman-core.alsa-project.org

if I try to apply it the top of the commit message looks like:

| commit 8f0e0ee514b189cf7b4e7fa09581e3f1d246fa09 (HEAD -> tmp)
| Author: Richard Fitzgerald via Alsa-devel <alsa-devel@alsa-project.org>
| Date:   Thu Apr 20 11:20:43 2023 +0100
|
|     ASoC: cs35l56: Remove duplicate mbox log messages
|    
|     Received: by alsa1.perex.cz (Postfix, from userid 50401)
|             id 7A47CF80155; Thu, 20 Apr 2023 12:20:56 +0200 (CEST)
|     X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on alsa1.perex.cz

with all the headers dumped in there which is just completely mangled.
Note the rewritten author.  

mutt also represents this incredibly badly, it just shows the
"attachment" as the body of the message with all the headers dumped in
like they're just plain text in the body of the mail - I wouldn't have
thought this was an attachment if it hadn't been mentioned in this
thread, none of the atacment UI shows.  To reverse the mangling you have
to view attachments then save the root of the message to a folder.  AIUI
mutt assumes that whatever the root of the message is is intended to be
the message body and does the best it can to display it as such.

Lore *does* show the body of the message as an attachment.

> As you see, the header and all signatures are correct in the attachment:

None of our tooling or processes understand this, they're working with
the top level message.

> > Is it possible to take steps to improve the reptuation of the ALSA
> > servers so this isn't needed, or could we migrate the lists elsewhere (I

> It is not possible to talk with gmail administrators. I tried that several
> times. The outgoing ALSA server is not on any spam list.

I know there is a lot of discussion going round about which hoops to
jump through to play nice with gmail, I don't know if there's any new
stuff that's come up there recently.

> > know we set up linux-sound@vger at one point with the idea of
> > migrating).

> I guess that the vger servers have similar issues, because servers with
> DMARC enabled on the ingress side can reject e-mails. It's related to e-mail
> standards.

The issue I'm seeing here is the rewriting which I'm not aware of any
other lists having turned on, even infradead ones which are also mailman
based.  Either they're just tolerating people having issues with gmail
(which seems reasonable TBH) or they're jumping through some additional
hoops to avoid issues.

I believe vger does sometimes manage some backchannel which probably
helps it somewhat.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Jaroslav Kysela]

On 09. 05. 23 16:35, Mark Brown wrote:
> On Tue, May 09, 2023 at 11:54:18AM +0200, Jaroslav Kysela wrote:
> 
>> The signature is correct in the encapsulated original e-mail. The b4 should
>> be improved in my opinion.
> 
> It's not b4 that's the issue here except in that it causes me to fetch
> copies of the message that went to the list instead of my inbox which
> didn't get mangled by the list.  git am just does not understand what's

b4 can detect, if the e-mail is wrapped and use only the wrapped message. The 
wrapping is the correct semantics per mailman 3 not mangling (see [1]).

https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html

> happening with attachments.  For example for:
> 
>     168198605952.26.13645408104113633580@mailman-core.alsa-project.org
> 
> if I try to apply it the top of the commit message looks like:
> 
> | commit 8f0e0ee514b189cf7b4e7fa09581e3f1d246fa09 (HEAD -> tmp)
> | Author: Richard Fitzgerald via Alsa-devel <alsa-devel@alsa-project.org>
> | Date:   Thu Apr 20 11:20:43 2023 +0100
> |
> |     ASoC: cs35l56: Remove duplicate mbox log messages
> |
> |     Received: by alsa1.perex.cz (Postfix, from userid 50401)
> |             id 7A47CF80155; Thu, 20 Apr 2023 12:20:56 +0200 (CEST)
> |     X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on alsa1.perex.cz
> 
> with all the headers dumped in there which is just completely mangled.
> Note the rewritten author.

You should apply the wrapped message not the capsule.

> mutt also represents this incredibly badly, it just shows the
> "attachment" as the body of the message with all the headers dumped in
> like they're just plain text in the body of the mail - I wouldn't have
> thought this was an attachment if it hadn't been mentioned in this
> thread, none of the atacment UI shows.  To reverse the mangling you have
> to view attachments then save the root of the message to a folder.  AIUI
> mutt assumes that whatever the root of the message is is intended to be
> the message body and does the best it can to display it as such.

I think that you can configure the tool to process this attachment in mutt.

> Lore *does* show the body of the message as an attachment.

Yes, the original message is in the attachment - no information is lost.

>> As you see, the header and all signatures are correct in the attachment:
> 
> None of our tooling or processes understand this, they're working with
> the top level message.
> 
>>> Is it possible to take steps to improve the reptuation of the ALSA
>>> servers so this isn't needed, or could we migrate the lists elsewhere (I
> 
>> It is not possible to talk with gmail administrators. I tried that several
>> times. The outgoing ALSA server is not on any spam list.
> 
> I know there is a lot of discussion going round about which hoops to
> jump through to play nice with gmail, I don't know if there's any new
> stuff that's come up there recently.
> 
>>> know we set up linux-sound@vger at one point with the idea of
>>> migrating).
> 
>> I guess that the vger servers have similar issues, because servers with
>> DMARC enabled on the ingress side can reject e-mails. It's related to e-mail
>> standards.
> 
> The issue I'm seeing here is the rewriting which I'm not aware of any
> other lists having turned on, even infradead ones which are also mailman
> based.  Either they're just tolerating people having issues with gmail
> (which seems reasonable TBH) or they're jumping through some additional
> hoops to avoid issues.

I checked infradead and they're using mailman 2. Mailman 2 does not support 
DMARC mitigation.

> I believe vger does sometimes manage some backchannel which probably
> helps it somewhat.

Using a non-standard mechanism is not a big win.

DMARC is a internet standard - see RFC7489, RFC8616. It means that the mailing 
lists cannot send e-mails with From from other domains which have restricted 
policies set by *their* administrators. So basically, all mail servers 
violates this if they keep the From header. Mailman 3 implemented several 
types of mitigations and the message wrap is the best one in my eyes. The 
mangling of the From header or reject e-mails from those senders is even worse 
(see [1]).

When I turn off the mitigation in mailman, my ALSA server will have bad 
reputation for gmail users soon in an unpredictable manner. I also saw that 
ATT incoming mail servers had similar issues. We can expect that the list of 
the ingress SMTP servers not accepting e-mails based on the DMARC policy will 
grow. It's something that we don't have under control.

If we don't find that it's time to move forward and accept this policy, I can 
turn off the mitigation, but in a cost that gmail (and soon maybe other) users 
will bomb me (they already did last years) that the ALSA mail server does not 
deliver e-mails for them. Are we a community on internet or not?

Ideally, we should start upgrade and fix our tools...

Let me just know, if you (and Takashi) insist to turn the mitigation off after 
this discussion. I'll do so...

					Jaroslav

[1] 
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Konstantin Ryabitsev]

On Tue, May 09, 2023 at 08:03:39PM +0200, Jaroslav Kysela wrote:
> DMARC is a internet standard - see RFC7489, RFC8616. It means that the
> mailing lists cannot send e-mails with From from other domains which have
> restricted policies set by *their* administrators. So basically, all mail
> servers violates this if they keep the From header.

This is not correct. Operating a mailing list server is perfectly
DMARC-compliant as long as:

- messages have DKIM signatures
- ML software doesn't modify any of the signed headers
- ML software doesn't touch the body

-K

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 5280 bytes --]

On Tue, May 09, 2023 at 08:03:39PM +0200, Jaroslav Kysela wrote:
> On 09. 05. 23 16:35, Mark Brown wrote:

> > It's not b4 that's the issue here except in that it causes me to fetch
> > copies of the message that went to the list instead of my inbox which
> > didn't get mangled by the list.  git am just does not understand what's

> b4 can detect, if the e-mail is wrapped and use only the wrapped message.
> The wrapping is the correct semantics per mailman 3 not mangling (see [1]).

> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html

As Konstantin pointed out this isn't entirely practical, especially with
the message ID rewriting breaking things.  I suspect any mitigation here
would have to be on the archive side with it trying to unpack and
archive the enclosed message but that doesn't deal with all the issues.

> > if I try to apply it the top of the commit message looks like:

> > | commit 8f0e0ee514b189cf7b4e7fa09581e3f1d246fa09 (HEAD -> tmp)
> > | Author: Richard Fitzgerald via Alsa-devel <alsa-devel@alsa-project.org>
> > | Date:   Thu Apr 20 11:20:43 2023 +0100

> > with all the headers dumped in there which is just completely mangled.
> > Note the rewritten author.

> You should apply the wrapped message not the capsule.

That's just not how any of the tooling works here, it is *possible* to
unpack things but it's really fighting against the tooling.

> > mutt also represents this incredibly badly, it just shows the
> > "attachment" as the body of the message with all the headers dumped in

> I think that you can configure the tool to process this attachment in mutt.

I don't know off hand what that configuration would be, and in any case
it'd have knock on effects with reordering messages in the mailboxes
plus the overhead of having to open the mailbox to figure out if there's
any mangled messages in there.

> > The issue I'm seeing here is the rewriting which I'm not aware of any
> > other lists having turned on, even infradead ones which are also mailman
> > based.  Either they're just tolerating people having issues with gmail
> > (which seems reasonable TBH) or they're jumping through some additional
> > hoops to avoid issues.

> I checked infradead and they're using mailman 2. Mailman 2 does not support
> DMARC mitigation.

AFAICT that "mitigation" is actively harmful...

> > I believe vger does sometimes manage some backchannel which probably
> > helps it somewhat.

> Using a non-standard mechanism is not a big win.

> DMARC is a internet standard - see RFC7489, RFC8616. It means that the
> mailing lists cannot send e-mails with From from other domains which have
> restricted policies set by *their* administrators. So basically, all mail

I'm perfectly aware of what DMARC is, though I've not run a list server
since it became a thing.  As far as I'm aware the backchannel stuff for
vger is more on the policy front (eg, with stuff like rate limit based
mitigations) and not anything to do with relaxing any standards based
security.

> servers violates this if they keep the From header. Mailman 3 implemented
> several types of mitigations and the message wrap is the best one in my
> eyes. The mangling of the From header or reject e-mails from those senders
> is even worse (see [1]).

AFAICT the only other option is munging the From without enclosing the
message in a wrapper?  That's potentially marginally less harmful but
it's still going to break things badly enough that I'm not sure it's a
worthwhile improvement.

> When I turn off the mitigation in mailman, my ALSA server will have bad
> reputation for gmail users soon in an unpredictable manner. I also saw that
> ATT incoming mail servers had similar issues. We can expect that the list of
> the ingress SMTP servers not accepting e-mails based on the DMARC policy
> will grow. It's something that we don't have under control.

It's not quite that broken.

> If we don't find that it's time to move forward and accept this policy, I
> can turn off the mitigation, but in a cost that gmail (and soon maybe other)
> users will bomb me (they already did last years) that the ALSA mail server
> does not deliver e-mails for them. Are we a community on internet or not?

> Ideally, we should start upgrade and fix our tools...

> Let me just know, if you (and Takashi) insist to turn the mitigation off
> after this discussion. I'll do so...

I'd really like to see it turned off, in conjunction with the
suggestions from Konstantin for passing DMARC.  As far as I can tell the
standards are not so broken as to be unusable, though any list is going
to have some issues with gmail due to things like people incorrectly
reporting spam (eg, when they want to unsubscribe or didn't realise what
sort of list they were signing up for),

For the signatures thing IIRC even before this change to wrap things the
list server was mangling incoming siguatures, they'd typically not
verify if they came through the list - I never checked into it fully
since it was just something I had to be aware of but that's been there
since b4 had signature verification.  I *think* ideally existing
signatures should be preserved, or a new one added if there is none.
That may well be more of the issue than anything else.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Chen-Yu Tsai]

On Wed, May 10, 2023 at 10:08 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, May 09, 2023 at 08:03:39PM +0200, Jaroslav Kysela wrote:
> > On 09. 05. 23 16:35, Mark Brown wrote:
>
> > > It's not b4 that's the issue here except in that it causes me to fetch
> > > copies of the message that went to the list instead of my inbox which
> > > didn't get mangled by the list.  git am just does not understand what's
>
> > b4 can detect, if the e-mail is wrapped and use only the wrapped message.
> > The wrapping is the correct semantics per mailman 3 not mangling (see [1]).
>
> > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html
>
> As Konstantin pointed out this isn't entirely practical, especially with
> the message ID rewriting breaking things.  I suspect any mitigation here
> would have to be on the archive side with it trying to unpack and
> archive the enclosed message but that doesn't deal with all the issues.
>
> > > if I try to apply it the top of the commit message looks like:
>
> > > | commit 8f0e0ee514b189cf7b4e7fa09581e3f1d246fa09 (HEAD -> tmp)
> > > | Author: Richard Fitzgerald via Alsa-devel <alsa-devel@alsa-project.org>
> > > | Date:   Thu Apr 20 11:20:43 2023 +0100
>
> > > with all the headers dumped in there which is just completely mangled.
> > > Note the rewritten author.
>
> > You should apply the wrapped message not the capsule.
>
> That's just not how any of the tooling works here, it is *possible* to
> unpack things but it's really fighting against the tooling.
>
> > > mutt also represents this incredibly badly, it just shows the
> > > "attachment" as the body of the message with all the headers dumped in
>
> > I think that you can configure the tool to process this attachment in mutt.
>
> I don't know off hand what that configuration would be, and in any case
> it'd have knock on effects with reordering messages in the mailboxes
> plus the overhead of having to open the mailbox to figure out if there's
> any mangled messages in there.
>
> > > The issue I'm seeing here is the rewriting which I'm not aware of any
> > > other lists having turned on, even infradead ones which are also mailman
> > > based.  Either they're just tolerating people having issues with gmail
> > > (which seems reasonable TBH) or they're jumping through some additional
> > > hoops to avoid issues.
>
> > I checked infradead and they're using mailman 2. Mailman 2 does not support
> > DMARC mitigation.
>
> AFAICT that "mitigation" is actively harmful...
>
> > > I believe vger does sometimes manage some backchannel which probably
> > > helps it somewhat.
>
> > Using a non-standard mechanism is not a big win.
>
> > DMARC is a internet standard - see RFC7489, RFC8616. It means that the
> > mailing lists cannot send e-mails with From from other domains which have
> > restricted policies set by *their* administrators. So basically, all mail
>
> I'm perfectly aware of what DMARC is, though I've not run a list server
> since it became a thing.  As far as I'm aware the backchannel stuff for
> vger is more on the policy front (eg, with stuff like rate limit based
> mitigations) and not anything to do with relaxing any standards based
> security.
>
> > servers violates this if they keep the From header. Mailman 3 implemented
> > several types of mitigations and the message wrap is the best one in my
> > eyes. The mangling of the From header or reject e-mails from those senders
> > is even worse (see [1]).
>
> AFAICT the only other option is munging the From without enclosing the
> message in a wrapper?  That's potentially marginally less harmful but
> it's still going to break things badly enough that I'm not sure it's a
> worthwhile improvement.
>
> > When I turn off the mitigation in mailman, my ALSA server will have bad
> > reputation for gmail users soon in an unpredictable manner. I also saw that
> > ATT incoming mail servers had similar issues. We can expect that the list of
> > the ingress SMTP servers not accepting e-mails based on the DMARC policy
> > will grow. It's something that we don't have under control.
>
> It's not quite that broken.
>
> > If we don't find that it's time to move forward and accept this policy, I
> > can turn off the mitigation, but in a cost that gmail (and soon maybe other)
> > users will bomb me (they already did last years) that the ALSA mail server
> > does not deliver e-mails for them. Are we a community on internet or not?
>
> > Ideally, we should start upgrade and fix our tools...
>
> > Let me just know, if you (and Takashi) insist to turn the mitigation off
> > after this discussion. I'll do so...
>
> I'd really like to see it turned off, in conjunction with the
> suggestions from Konstantin for passing DMARC.  As far as I can tell the
> standards are not so broken as to be unusable, though any list is going
> to have some issues with gmail due to things like people incorrectly
> reporting spam (eg, when they want to unsubscribe or didn't realise what
> sort of list they were signing up for),
>
> For the signatures thing IIRC even before this change to wrap things the
> list server was mangling incoming siguatures, they'd typically not
> verify if they came through the list - I never checked into it fully
> since it was just something I had to be aware of but that's been there
> since b4 had signature verification.  I *think* ideally existing
> signatures should be preserved, or a new one added if there is none.
> That may well be more of the issue than anything else.

Last time this topic was raised (on infradead), I talked to someone from
Gmail. The ask was that originating servers implement DKIM signing, and
intermediate servers, i.e. mailing lists, not mangle the signed fields.
The latter includes not adding footers, and not re-emitting headers, which
may alter the amount of whitespace, based on some of my experiments.

ChenYu

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Geraldo Nascimento]

On Wed, May 10, 2023 at 11:05:59AM +0900, Mark Brown wrote:
> AFAICT the only other option is munging the From without enclosing the
> message in a wrapper?  That's potentially marginally less harmful but
> it's still going to break things badly enough that I'm not sure it's a
> worthwhile improvement.

The readymade mitigations for DMARC in mailman 3 are
"munge_from" and "wrap_message". The fact "wrap_message" messes
around with signatures in mutt is definitely not a good sign,
and "munge_from" will change the author's email and name from
the perspective of git-am.

The middle way could be to patch mailman 3 to "munge_from" while adding
the correct "From:" as the first thing in the body of the message if it
doesn't contain one already. This will make git-am pickup the correct
author's details and it should be some simple logic.

If Jaroslav is brave enough to maintain this supposed patch to mailman 3
in case it doesn't get picked-up upstream by the FSF folks...

I understand the maintainers needs must come first but it will be
terrible to get the GMail bouncing behaviour again, I don't want to
press the point since Jaroslav already made the speech I think it
was needed.

Thanks,
Geraldo Nascimento

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Jaroslav Kysela]

On 10. 05. 23 5:58, Geraldo Nascimento wrote:
> On Wed, May 10, 2023 at 11:05:59AM +0900, Mark Brown wrote:
>> AFAICT the only other option is munging the From without enclosing the
>> message in a wrapper?  That's potentially marginally less harmful but
>> it's still going to break things badly enough that I'm not sure it's a
>> worthwhile improvement.
> 
> The readymade mitigations for DMARC in mailman 3 are
> "munge_from" and "wrap_message". The fact "wrap_message" messes
> around with signatures in mutt is definitely not a good sign,
> and "munge_from" will change the author's email and name from
> the perspective of git-am.
> 
> The middle way could be to patch mailman 3 to "munge_from" while adding
> the correct "From:" as the first thing in the body of the message if it
> doesn't contain one already. This will make git-am pickup the correct
> author's details and it should be some simple logic.

Unfortunately, changing the message body will break the DKIM message integrity 
(body hash)...

				Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Konstantin Ryabitsev]

On Wed, May 10, 2023 at 08:17:30AM +0200, Jaroslav Kysela wrote:
> > The middle way could be to patch mailman 3 to "munge_from" while adding
> > the correct "From:" as the first thing in the body of the message if it
> > doesn't contain one already. This will make git-am pickup the correct
> > author's details and it should be some simple logic.
> 
> Unfortunately, changing the message body will break the DKIM message
> integrity (body hash)...

If you change the From: header, the DKIM signature doesn't matter any more, so
this will work just fine.

-K

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Geraldo Nascimento]

On Wed, May 10, 2023 at 11:13:15AM -0400, Konstantin Ryabitsev wrote:
> On Wed, May 10, 2023 at 08:17:30AM +0200, Jaroslav Kysela wrote:
> > > The middle way could be to patch mailman 3 to "munge_from" while adding
> > > the correct "From:" as the first thing in the body of the message if it
> > > doesn't contain one already. This will make git-am pickup the correct
> > > author's details and it should be some simple logic.
> > 
> > Unfortunately, changing the message body will break the DKIM message
> > integrity (body hash)...
> 
> If you change the From: header, the DKIM signature doesn't matter any more, so
> this will work just fine.

Hi Konstantin,

I'm reading RFC 6377 from September 2001, "DKIM and Mailing Lists", and
the approach you say would work just fine I think is covered on section
5.7.,  "Signature Removal Issues".

Regards,
Geraldo Nascimento

> 
> -K

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Konstantin Ryabitsev]

On Tue, May 09, 2023 at 11:54:18AM +0200, Jaroslav Kysela wrote:
> The signature is correct in the encapsulated original e-mail. The b4 should
> be improved in my opinion.

This is non-fixable. The "mitigations" send messages with a completely
different message-id, and this breaks pretty much everything. For example, a
message sent to another list would have the original message-id, but a
different one if someone retrieves it via the alsa-project subscription. So,
if someone responds to the message with the bogus rewritten message-id, it
would be in the wrong place in the thread.

This is just not usable for patch workflows.

> For example, here is the original message:
> 
> https://lore.kernel.org/alsa-devel/168311377075.26.14919941665402646886@mailman-core.alsa-project.org/

This demonstrates the above problem. This message has a bogus message-id, but
it sets in-reply-to of the cover letter. Someone sending their reviewed-by
trailer to this patch would, in fact, send it with the cover letter as the
parent (meaning it should apply to the entire series).

> I guess that the vger servers have similar issues, because servers with
> DMARC enabled on the ingress side can reject e-mails. It's related to e-mail
> standards.

It is perfectly possible to operate a mailing list server and be
DMARC-compliant (at least for DKIM-signed messages) without requiring any of
the horrible things mailman-3 is doing:

https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html

-K

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Jaroslav Kysela]

On 09. 05. 23 20:22, Konstantin Ryabitsev wrote:
> On Tue, May 09, 2023 at 11:54:18AM +0200, Jaroslav Kysela wrote:
>> The signature is correct in the encapsulated original e-mail. The b4 should
>> be improved in my opinion.
> 
> This is non-fixable. The "mitigations" send messages with a completely
> different message-id, and this breaks pretty much everything. For example, a
> message sent to another list would have the original message-id, but a
> different one if someone retrieves it via the alsa-project subscription. So,
> if someone responds to the message with the bogus rewritten message-id, it
> would be in the wrong place in the thread.
> 
> This is just not usable for patch workflows.
> 
>> For example, here is the original message:
>>
>> https://lore.kernel.org/alsa-devel/168311377075.26.14919941665402646886@mailman-core.alsa-project.org/
> 
> This demonstrates the above problem. This message has a bogus message-id, but
> it sets in-reply-to of the cover letter. Someone sending their reviewed-by
> trailer to this patch would, in fact, send it with the cover letter as the
> parent (meaning it should apply to the entire series).

The tools should be improved IMHO. The capsule contains References: so if 
tools extract the wrapped e-mail to get the original Message-ID:, we're good.

>> I guess that the vger servers have similar issues, because servers with
>> DMARC enabled on the ingress side can reject e-mails. It's related to e-mail
>> standards.
> 
> It is perfectly possible to operate a mailing list server and be
> DMARC-compliant (at least for DKIM-signed messages) without requiring any of
> the horrible things mailman-3 is doing:
> 
> https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html

I wish that it was as easy. I don't see any references to RFCs in this text, 
so we cannot verify the contents. As our mailing list does not modify the 
headers and body, the DKIM is correct for our messages, but it does not work 
practically (the mitigation was turned on recently, so I know how many bounces 
were present).

Also, RFC7960 does not describe this:

https://datatracker.ietf.org/doc/html/rfc7960#section-4.1.3

especially:

https://datatracker.ietf.org/doc/html/rfc7960#section-3.2.3

and see note in:

https://datatracker.ietf.org/doc/html/rfc7960#section-3.2.3.1

So "keep everything unmodified" for DKIM is just only one part of the problem. 
Perhaps, there's a RFC update somewhere which adds another note.

				Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Konstantin Ryabitsev]

On Wed, May 10, 2023 at 09:50:24AM +0200, Jaroslav Kysela wrote:
> > It is perfectly possible to operate a mailing list server and be
> > DMARC-compliant (at least for DKIM-signed messages) without requiring any of
> > the horrible things mailman-3 is doing:
> > 
> > https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html
> 
> I wish that it was as easy.

It is. We've been operating DMARC-compliant mailing lists for many years now
without needing to mangle any messages.

> I don't see any references to RFCs in this text,
> so we cannot verify the contents. As our mailing list does not modify the
> headers and body, the DKIM is correct for our messages, but it does not work
> practically (the mitigation was turned on recently, so I know how many
> bounces were present).

Can you please show me the message that was no longer DMARC-compliant after
passing through your mailing list server? I will point out what made them
non-DMARC-compliant, and it won't be some builtin incompatibility between
DMARC and mailing lists.

> Also, RFC7960 does not describe this:
> 
> https://datatracker.ietf.org/doc/html/rfc7960#section-4.1.3
> 
> especially:
> 
> https://datatracker.ietf.org/doc/html/rfc7960#section-3.2.3

These talk specifically about messages that were modified by the mailing list
software.

> and see note in:
> 
> https://datatracker.ietf.org/doc/html/rfc7960#section-3.2.3.1
> 
> So "keep everything unmodified" for DKIM is just only one part of the
> problem. Perhaps, there's a RFC update somewhere which adds another note.

I can demonstrate to you millions of email messages that passed through the
mailing list that are still perfectly DMARC compliant -- you seem convinced
that it's not possible. For example, here's the authentication header set by
GMail for a message that I recently received via the tools mailing list:

	Authentication-Results: mx.google.com;
		   dkim=pass header.i=@gmail.com header.s=20221208 header.b=YVg2o3VH;
		   spf=pass (google.com: domain of [omitted]@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=[omitted]@gmail.com;
		   dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com

So, I'm just going to repeat this: operating a mailing list and remaining
DMARC compliant is perfectly possible, provided:

- the original message is DKIM-signed
- all existing headers are unmodified
- the message body is unmodified

-K

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Jaroslav Kysela]

On 10. 05. 23 17:34, Konstantin Ryabitsev wrote:

> So, I'm just going to repeat this: operating a mailing list and remaining
> DMARC compliant is perfectly possible, provided:
> 
> - the original message is DKIM-signed
> - all existing headers are unmodified
> - the message body is unmodified

Example of e-mail which is rejected by google's mx servers:

https://lore.kernel.org/alsa-devel/20230510142227.32945-1-vitalyr@opensource.cirrus.com/raw

 From the postfix e-mail queue:

https://gist.github.com/perexg/ac06eacd8b3a8f741ef5602ec748e0a8

SMTP error:

reason=host alt1.aspmx.l.google.com[142.251.9.27] said: 550-5.7.26 
Unauthenticated email from cirrus.com is not accepted due to domain's 
550-5.7.26 DMARC policy. Please contact the administrator of cirrus.com domain 
550-5.7.26 if this was a legitimate mail. Please visit 550-5.7.26 
https://support.google.com/mail/answer/2451690 to learn about the 450 4.7.26 
DMARC initiative. mz11-20020a1709071b8b00b009665976cbddsi3525670ejc.170 - 
gsmtp (in reply to end of DATA command)

				Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Konstantin Ryabitsev]

On Wed, May 10, 2023 at 06:19:15PM +0200, Jaroslav Kysela wrote:
> On 10. 05. 23 17:34, Konstantin Ryabitsev wrote:
> 
> > So, I'm just going to repeat this: operating a mailing list and remaining
> > DMARC compliant is perfectly possible, provided:
> > 
> > - the original message is DKIM-signed
> > - all existing headers are unmodified
> > - the message body is unmodified
> 
> Example of e-mail which is rejected by google's mx servers:
> 
> https://lore.kernel.org/alsa-devel/20230510142227.32945-1-vitalyr@opensource.cirrus.com/raw

Thank you for this example -- it plainly illustrates the problem, which is
that Mailman 3 mangles messages.

If you compare the above message with the message that passed via vger, you
will notice what went wrong:

    -CC:     <alsa-devel@alsa-project.org>, <patches@opensource.cirrus.com>,
    -        <linux-kernel@vger.kernel.org>,
    -        Vitaly Rodionov <vitalyr@opensource.cirrus.com>
    +CC: alsa-devel@alsa-project.org, patches@opensource.cirrus.com,
    + linux-kernel@vger.kernel.org, Vitaly Rodionov <vitalyr@opensource.cirrus.com>

For some bizarre reason Mailman-3 decided to make the CC header "more pretty"
by stripping the angle brackets around addresses. Since it's a DKIM-signed
header, this invalidates the signature and results in DMARC violations.

The answer, unfortunately, is to stop using Mailman-3. It's not usable for
patch-based workflows.

-K

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Jaroslav Kysela]

On 10. 05. 23 18:43, Konstantin Ryabitsev wrote:
> On Wed, May 10, 2023 at 06:19:15PM +0200, Jaroslav Kysela wrote:
>> On 10. 05. 23 17:34, Konstantin Ryabitsev wrote:
>>
>>> So, I'm just going to repeat this: operating a mailing list and remaining
>>> DMARC compliant is perfectly possible, provided:
>>>
>>> - the original message is DKIM-signed
>>> - all existing headers are unmodified
>>> - the message body is unmodified
>>
>> Example of e-mail which is rejected by google's mx servers:
>>
>> https://lore.kernel.org/alsa-devel/20230510142227.32945-1-vitalyr@opensource.cirrus.com/raw
> 
> Thank you for this example -- it plainly illustrates the problem, which is
> that Mailman 3 mangles messages.
> 
> If you compare the above message with the message that passed via vger, you
> will notice what went wrong:
> 
>      -CC:     <alsa-devel@alsa-project.org>, <patches@opensource.cirrus.com>,
>      -        <linux-kernel@vger.kernel.org>,
>      -        Vitaly Rodionov <vitalyr@opensource.cirrus.com>
>      +CC: alsa-devel@alsa-project.org, patches@opensource.cirrus.com,
>      + linux-kernel@vger.kernel.org, Vitaly Rodionov <vitalyr@opensource.cirrus.com>
> 
> For some bizarre reason Mailman-3 decided to make the CC header "more pretty"
> by stripping the angle brackets around addresses. Since it's a DKIM-signed
> header, this invalidates the signature and results in DMARC violations.
> 
> The answer, unfortunately, is to stop using Mailman-3. It's not usable for
> patch-based workflows.

Whoops. It seems that mm3 guys knows about it:

https://gitlab.com/mailman/mailman/-/merge_requests/1039

I tried to apply the noted workaround. Crossing fingers.

Thank you for your help.

						Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Wed, May 10, 2023 at 08:38:03PM +0200, Jaroslav Kysela wrote:
> On 10. 05. 23 18:43, Konstantin Ryabitsev wrote:

> > Thank you for this example -- it plainly illustrates the problem, which is
> > that Mailman 3 mangles messages.

> Whoops. It seems that mm3 guys knows about it:

> https://gitlab.com/mailman/mailman/-/merge_requests/1039

> I tried to apply the noted workaround. Crossing fingers.

> Thank you for your help.

That's great - hopefully that resolves everything!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Geraldo Nascimento]

On Tue, May 09, 2023 at 09:12:55AM +0200, Jaroslav Kysela wrote:
> I am open to any suggestions, but the default mailman settings (do not do 
> anything) causes that some (mostly gmail) users do not receive their e-mails 
> because the ALSA's mail server has a bad reputation. Many companies are using 
> the google mail service for their domains nowadays.
>

As a GMail user, I can confirm that I'm not seeing any more bounces
after mangling started. Usually it'd bounce and I'd have to login to the
web interface to turn back on my subscription, a real pain.

> 
> 					Jaroslav
> 
> -- 
> Jaroslav Kysela <perex@perex.cz>
> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
> 

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Chen-Yu Tsai]

On Wed, May 10, 2023 at 1:52 AM Geraldo Nascimento
<geraldogabriel@gmail.com> wrote:
>
> On Tue, May 09, 2023 at 09:12:55AM +0200, Jaroslav Kysela wrote:
> > I am open to any suggestions, but the default mailman settings (do not do
> > anything) causes that some (mostly gmail) users do not receive their e-mails
> > because the ALSA's mail server has a bad reputation. Many companies are using
> > the google mail service for their domains nowadays.
> >
>
> As a GMail user, I can confirm that I'm not seeing any more bounces
> after mangling started. Usually it'd bounce and I'd have to login to the
> web interface to turn back on my subscription, a real pain.

FWIW the dri-devel mailing list seems to implement an alternative strategy
for dealing with Gmail and co. bouncing messages. If it gets bounces it will
send a separate "bounce probe" email including details about what bounced.
It will not just deactivate a subscription due to bounces.

Also, ALSA's mailing list now requires a subscriber to register a user
account to resume delivery is a bit annoying.


ChenYu

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])

[Jaroslav Kysela]

On 10. 05. 23 5:01, Chen-Yu Tsai wrote:
> On Wed, May 10, 2023 at 1:52 AM Geraldo Nascimento
> <geraldogabriel@gmail.com> wrote:
>>
>> On Tue, May 09, 2023 at 09:12:55AM +0200, Jaroslav Kysela wrote:
>>> I am open to any suggestions, but the default mailman settings (do not do
>>> anything) causes that some (mostly gmail) users do not receive their e-mails
>>> because the ALSA's mail server has a bad reputation. Many companies are using
>>> the google mail service for their domains nowadays.
>>>
>>
>> As a GMail user, I can confirm that I'm not seeing any more bounces
>> after mangling started. Usually it'd bounce and I'd have to login to the
>> web interface to turn back on my subscription, a real pain.
> 
> FWIW the dri-devel mailing list seems to implement an alternative strategy
> for dealing with Gmail and co. bouncing messages. If it gets bounces it will
> send a separate "bounce probe" email including details about what bounced.
> It will not just deactivate a subscription due to bounces.

The probes are enabled for the ALSA's mailing lists, but when the incoming 
servers decide to not accept any e-mails (as gmail does), they will be lost.

> Also, ALSA's mailing list now requires a subscriber to register a user
> account to resume delivery is a bit annoying.

I tried to set higher thresholds for bounces.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]

[Geraldo Nascimento]

On Thu, May 04, 2023 at 10:09:45AM +0900, Mark Brown wrote:
> Hi,
> 
> Here's another mail (one of several in this series) that got completely
> mangled by the alsa-project.org mailman to the point of unusability.  I
> didn't see any response to my last mail about this, is there any news on
> fixing mailman to not do this?  It's extremely disruptive to working
> with lore.

Hi Mark,

Are you complaining about the added headers in the message? Because the
patch itself didn't look mangled from my side. From my understanding,
Jaroslav had to start mangling mail addresses due to strict DMARC rules
which make some servers reject the message from alsa-devel.

Thanks,
Geraldo Nascimento

> 
> Thanks,
> Mark

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

On Fri, May 05, 2023 at 05:38:28PM -0300, Geraldo Nascimento wrote:
> On Thu, May 04, 2023 at 10:09:45AM +0900, Mark Brown wrote:

> > Here's another mail (one of several in this series) that got completely
> > mangled by the alsa-project.org mailman to the point of unusability.  I
> > didn't see any response to my last mail about this, is there any news on
> > fixing mailman to not do this?  It's extremely disruptive to working
> > with lore.

> Are you complaining about the added headers in the message? Because the
> patch itself didn't look mangled from my side. From my understanding,
> Jaroslav had to start mangling mail addresses due to strict DMARC rules
> which make some servers reject the message from alsa-devel.

Not just the headers in the message, the author information for the mail
also got rewritten.  Try applying the patches with git am...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]

[Geraldo Nascimento]

On Sat, May 06, 2023 at 09:13:06AM +0900, Mark Brown wrote:
> On Fri, May 05, 2023 at 05:38:28PM -0300, Geraldo Nascimento wrote:
> > On Thu, May 04, 2023 at 10:09:45AM +0900, Mark Brown wrote:
> 
> > > Here's another mail (one of several in this series) that got completely
> > > mangled by the alsa-project.org mailman to the point of unusability.  I
> > > didn't see any response to my last mail about this, is there any news on
> > > fixing mailman to not do this?  It's extremely disruptive to working
> > > with lore.
> 
> > Are you complaining about the added headers in the message? Because the
> > patch itself didn't look mangled from my side. From my understanding,
> > Jaroslav had to start mangling mail addresses due to strict DMARC rules
> > which make some servers reject the message from alsa-devel.
> 
> Not just the headers in the message, the author information for the mail
> also got rewritten.  Try applying the patches with git am...

Mark, I think Jaroslav can change the behaviour in the the added Headers in the
body of the message (the added Headers in the body have e.g. the correct From:
email information).

If the message body *starts* with the "From:", "Subject:" and "Date:" fields
I think git-am will pickup the correct information from the body instead of from
the mangled headers.

Hopefully...

Good luck,
Geraldo Nascimento

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

On Fri, May 05, 2023 at 11:17:19PM -0300, Geraldo Nascimento wrote:
> On Sat, May 06, 2023 at 09:13:06AM +0900, Mark Brown wrote:

> > Not just the headers in the message, the author information for the mail
> > also got rewritten.  Try applying the patches with git am...

> Mark, I think Jaroslav can change the behaviour in the the added Headers in the
> body of the message (the added Headers in the body have e.g. the correct From:
> email information).

> If the message body *starts* with the "From:", "Subject:" and "Date:" fields
> I think git-am will pickup the correct information from the body instead of from
> the mangled headers.

> Hopefully...

No, it absolutely doesn't work properly - I only noticed this was
happening because b4/lore keep picking the copy from alsa-devel which is
mangled to the point of not being usable.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]

[Geraldo Nascimento]

On Mon, May 08, 2023 at 08:33:59AM +0900, Mark Brown wrote:
> On Fri, May 05, 2023 at 11:17:19PM -0300, Geraldo Nascimento wrote:
> > On Sat, May 06, 2023 at 09:13:06AM +0900, Mark Brown wrote:
> 
> > > Not just the headers in the message, the author information for the mail
> > > also got rewritten.  Try applying the patches with git am...
> 
> > Mark, I think Jaroslav can change the behaviour in the the added Headers in the
> > body of the message (the added Headers in the body have e.g. the correct From:
> > email information).
> 
> > If the message body *starts* with the "From:", "Subject:" and "Date:" fields
> > I think git-am will pickup the correct information from the body instead of from
> > the mangled headers.
> 
> > Hopefully...
> 
> No, it absolutely doesn't work properly - I only noticed this was
> happening because b4/lore keep picking the copy from alsa-devel which is
> mangled to the point of not being usable.

Hi Mark, sorry to hear that. The fact mailman is disrupting your
workflow as ASoC maintainer is alarming, and I hope you and Jaroslav can
work out a solution. But besides my suggestion that the added headers in
the body of the message *start* with at least the correct "From:" field,
I can't be of much help.

Thanks for the hard work,
Geraldo Nascimento