On Tue, 21 Sept 2021 at 17:59, Torge Riedel <torgeriedel@gmx.de> wrote:

Am 21.09.21 um 15:20 schrieb Philip Colmer:

...

sharing your configuration

I do. What configuration do you need? There is no special rspamd config in mailman3 on my setup.

I'm specifically after the full configuration for arc and dkim_signing, i.e. the output from "rspamadm configdump arc" and "rspamadm configdump dkim_signing".

I'm having a lot of trouble getting DKIM headers rewritten by Rspamd after Mailman 3 has altered the subject line and added the signature to the body and that, in turn, seems to then be causing Rspamd to not add the ARC headers.

I'm hoping that if I can see a working config, I'll then be able to get it all sorted out.

Many thanks.

Philip

On Wed, 22 Sept 2021 at 10:14, Bjoern Franke via Mailman-users <mailman-users@mailman3.org> wrote:

Hi,

...

I'm having a lot of trouble getting DKIM headers rewritten by Rspamd after Mailman 3 has altered the subject line and added the signature to the body and that, in turn, seems to then be causing Rspamd to not add the ARC headers.

why don't you let Mailman3 do the DMARC mitigation?

That is certainly an option. My main concern with this approach is that it needs to be configured on a per-list basis, as far as I can tell. My preference is to try and find an approach that works without modifying the settings per-list.

I'll do some more testing with DMARC mitigation enabled to review the Rspamd logs under that scenario and see what breaks then. I'm starting to think that there might be a bug in Rspamd so my other next step is to revert to OpenDKIM for the DKIM headers and use Rspamd for the ARC headers (since I couldn't get OpenARC to work).

Regards

Philip

On Thu, 23 Sept 2021 at 06:19, Torge Riedel <torgeriedel@gmx.de> wrote:

Am 22.09.21 um 11:20 schrieb Philip Colmer:

...

why don't you let Mailman3 do the DMARC mitigation?

I do have DMARC mitigation activated in mailman3, so that all mails sent are coming from a unique mail for each list. Some list members have strict SPF setups forcing me to do that.

Just to confirm, the DMARC mitigation action is "Replace From: with list address" and DMARC mitigate unconditionally set to Yes?

Following the config, I use rspamd from http://rspamd.com/apt-stable/

I was using the ASAN build but I've switched back to the normal build just for consistency. Version is 3.0-2~focal

rspamadm configdump arc *** Section arc *** sign_networks [ "127.2.4.7", ] use_domain = "recipient"; allow_envfrom_empty = true; allow_hdrfrom_multiple = false; allow_username_mismatch = true; sign_inbound = true; sign_local = false; symbol_sign = "ARC_SIGNED"; path = "/var/lib/rspamd/dkim/$selector.key"; try_fallback = true; use_redis = false; key_prefix = "ARC_KEYS"; allow_hdrfrom_mismatch = true; sign_authenticated = false; use_esld = true; selector = "2019";

*** End of section arc ***

rspamadm configdump dkim_signing *** Section dkim_signing *** sign_authenticated = true; use_esld = true; selector = "2019"; try_fallback = true; use_domain = "header"; allow_hdrfrom_mismatch = false; symbol = "DKIM_SIGNED"; allow_username_mismatch = true; allow_envfrom_empty = true; allow_hdrfrom_multiple = false; key_prefix = "DKIM_KEYS"; use_redis = false; sign_local = true; sign_networks [ "127.2.4.7", ] path = "/var/lib/rspamd/dkim/$selector.key";

*** End of section dkim_signing ***

Thanks for sharing that. There wasn't anything of substance that was different. I'm still hitting a problem though where the final receiving MTA says that the ARC header provided by Rspamd is invalid (BodyHash is different from the expected one). I have now submitted an issue on GitHub against Rspamd because I am concerned it is trying to apply ARC before it applies DKIM, which is incorrect.

Regards

Philip

Torge Riedel writes:

Am 23.09.21 um 09:56 schrieb Philip Colmer:

...

Just to confirm, the DMARC mitigation action is "Replace From: with list address" and DMARC mitigate unconditionally set to Yes?

"Replace From" is the recommendation ("Wrap Message" causes problems with many commonly-used mail clients).

"Mitigate Unconditionally" is a decision that is list-specific. For some lists mitigating only for authors whose sites publish "p=reject" and/or "p=quarantine" DMARC policies is a better choice. Factors include

1. Mitigation sometimes makes it hard to identify the actual author, for both mail clients and (more frequently) for human users.
2. Mitigation messes up the Reply-To process. Some subscribers will care, others won't even notice. Proportions differ for different lists.
3. The fraction of posters who use DMARC-paranoid sites.
4. Users may prefer a uniform look in the From header field, even if it's less accurate and convenient.
5. Conditional mitigation used to require installing an additional Python package (dnspython, IIRC) on some platforms. I think this is now an unconditional dependency for Mailman 3 itself, but not sure. Ie, unconditional mitigation does not require installing additional packages, conditional mitigation I'm only 99.44% sure.
6. List owner may be an RFC pedant (raises hand). Technically, RFC 5322 and predecessors strongly deprecate other agents changing the From header field. DMARC itself basically assumes that mail authors should not be using a "From" that triggers DMARC actions at any of their addressees. (This was explicit in some early drafts but was removed in mid-April 2014, I believe to shield AOL and Yahoo! from "nonconformance to your own RFC" criticism.)

I recall to had a bad mail reputation somewhere caused by mailman3 without DMARC mitigation. It only got better after changing the settings.

I'm sure this did happen. Changing the DMARC settings is a reasonable response.

Alternative perspective: I remove those addresses from my lists. ;-) (In fact, it's my email provider's policy: the Japanese government forbids use specifically of Yahoo! addresses for "government business", including public universities.)

Steve