Re: [Cfbl] Double DKIM signing

[Ken O'Driscoll <[e-mail]>]

Yes, that addresses the issue.

The problem with allowing senders any control over their mail service providers' ability to receive FBL reports, is bad senders. A bad sender will break their DNS so that DKIM fails if they think that that would reduce the number of complaints received in connection with their content.

Ken.

From: Cfbl <[e-mail]> On Behalf Of Jan-Philipp Benecke
Sent: Tuesday 28 June 2022 09:14
To: Ken O'Driscoll <ken=[e-mail]>
Cc: [e-mail]
Subject: Re: [Cfbl] Double DKIM signing

Ken O'Driscoll schrieb am 22.06.22 um 14:30:


First, I'd like to thank Jan-Philipp for all of the hard work they put in getting the first draft.

One thing that jumps out at me is the requirement for double DKIM signing (section 3.1.3). If I read this correctly, the draft requires that if the CFBL-Address domain is different to that of the 5322.From domain, then the message must also be DKIM signed using the 5322.From domain in order for the CFBL header to be considered valid. The draft claims that this is to ensure that the 5322.From domain owner consents to the CFBL-Address domain receiving reports.

Why is this desirable? In the most common use case for FBLs, that of a mail service provider adding the CFBL header with their own report address and sending messages on behalf of a sender's domain, the sender should not be able to decide what receivers can send complaints based on their messages. Surely that defeats the purpose of an FBL.

Further, the requirement for the 5322.From domain's signature to sign the CFBL headers makes optimistic assumptions about how much control senders may have over the first-hop MTAs which they use.

While there are other arguments for DKIM signing messages with the 5322.From domain, it shouldn't be a requirement for FBL reports to be generated.

Ken.
Thank you for your kind words and your feedback. I'm so sorry for the late reply.

The original intent was to have both parties agree to receive FBL messages via a third party address to prevent some sort of MITM attack.
For example, a malicious party changes the CFBL-Address to their domain and signs it while transfer.
However, this is also possible with any other header that is not signed with DKIM.

The following example considered valid then:

Return-Path: <[e-mail]><mailto:[e-mail]>
From: Awesome Newsletter <[e-mail]><mailto:[e-mail]>
To: [e-mail]<mailto:[e-mail]>
Subject: Super awesome deals for you
CFBL-Address: [e-mail]<mailto:[e-mail]>; report=arf
Message-ID: <[e-mail]><mailto:[e-mail]>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=super-saas-mailer.com; s=system;
       h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;

This way a mail service provider has the possibility to accept pre-signed mails from their senders and inject its own FBL report address.

I think this makes much more sense, what do you think? If so, I would change this with the next revision.

Again, thank you for bringing this up.

- JP