Ahoj, Dňa Wed, 8 Mar 2023 11:24:54 +0100 Alessandro Vesely via mailop <mailop@mailop.org> napísal:
> I slightly lean toward the hypothesis of our understanding the idea
> behind that RFC wrongly, because, ...
IMO we can discuss it in more details, but as i see how many people are
interested (and contributed) in this topic, we can (should) discuss it
out of list. If you are interested to continue, do not afraid contact
me directly (end we will see, if my English is enough for that). ;-)
> It was already discussed that the URL (presumably pointing to the
> same domain) must include an opaque token by which the target can
> check authenticity.
IMO purpose is (can be) to one (not always end user) can notice its
change before it post request to it... My MUAs doesn't support
one-click unsubscribes (or at least i am not aware of it), but
AFAIK there are others which do it. Signing that header, its value
becomes more trusted, with failed DKIM it becomes untrusted.
But that are only my thinking about it...
> I'm thinking to add a third header field list. From OpenDKIM, I have
> requiredhdrs, which are the header fields to be signed /if they
> exist/. Then I have oversignhdrs, which are the ones to
> unconditionally append to h=. The third list would contain the
> fields to be signed once even if they don't exist. I'd put Subject:,
> To: and Cc: in the third list, for example.
>
> Do you have such settings?
Of course, from start of my DKIM signing ;-)
I initially get inspiration from rspamd's default settings [1], which
use similar groups of headers. Exim allows me to define three types (per
header base):
+ sign if exists, oversign if not (Header)
+ always oversign (+Header)
+ sign if exists (=Header)
By using exim's expansions capability one can simple achieve fourth
possibility:
+ oversign if exists (${if def:h_Header:}{+Header}})
IMO that is the easier part. The hard part is to decide which header add
to which group and why/when. But for now i use one common list, which
differs on per message basis only by which headers are included, for
all domains. No more heuristics is applied.
From my notes (i have not as nice formatting in config, and i use
slightly different list now), but one can get idea (IIRC it was
rspamd's table converted to exim syntax) -- the colon is list item
separator:
+From:+Reply-To:+Subject:+To:+Cc\
${if def:h_Sender: {:+Sender}}\
${if def:h_Date: {:+Date}}\
${if def:h_Message-Id: {:+Message-Id}}\
${if def:h_Mime-Version: {:+Mime-Version}}\
${if def:h_Content-Description: {:+Content-Description}}\
${if def:h_Content-Id: {:+Content-Id}}\
${if def:h_Content-Type: {:+Content-Type}}\
${if def:h_Content-Type-Encoding: {:+Content-Type-Encoding}}\
${if def:h_In-Reply-To: {:+In-Reply-To}}\
${if def:h_References: {:+References}}\
${if def:h_Openpgp: {:+Openpgp}}\
${if def:h_Autocrypt: {:+Autocrypt}}\
:=Resent-To:=Resent-Cc:=Resent-Date:=Resent-From:=Resent-Sender:=Resent-Message-Id\
:=List-Archive:=List-Id:=List-Help:=List-Owner:=List-Unsubscribe:=List-Unsubscribe-Post\
:=List-Subscribe:=List-Post
This can be divided into three parts:
+ first line is always oversing list, doesn't matter if presented in
message or not
+ last three lines are sign, but only if presented in message
+ rest is oversign, if presented in message
BTW i revisited my idea about best practices. It can be as simple, as
list of headers, with three basic states -- always (over)sing, never
sign and "consider carefully". The last state then will be elaborated
more detailed, with description when and why it can be changed on
transport, to even inexperienced admins can understand/choose what is
appropriate. Eg with three column with cases -- when to sign, when to
oversign and when to not sign.
[1] https://rspamd.com/doc/modules/dkim_signing.html
> The change to multipart can only happen using the deprecated l=. It
> allows to completely replace the body appearance. As you don't use
> l=, the only added protection is against an improbable collision
> between the original bh= and the hash of the modified body.
Did you consider change only Content-Type, to fool clients to open body
in other application with same (yet unknown) vulnerability? My MUA
doesn't work with DKIM by any way, but others can, and failed DKIM can
contribute to score, that message can be rejected -- that is my idea.
You silently ignored my note, that i consider that header as
"constructing core of message", thus valid candidate to sign it.
Anyway, you described cases, where signing this header is not needed
as DKIM will fail anyway, and i agree. As i consider performance impact
to sign one more header as negligible, thus it must not matter. But
perhaps i ask wrong question, i will try another -- what is (can be)
wrong when it is signed?
regards
--
Slavko
https://www.slavino.sk
pgpNvZjtbY0c7.pgp
Description: Digitálny podpis OpenPGP
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
