I am trying to setup MTA using Postfix and using opendkim for dkim signing. When I went through opemdkim documentation it have a field which is named 'OversignHeaders' document describes it as: "Specifies a set of header fields that should be included in all signature header lists (the "h=" tag) once more than the number of times they were actually present in the signed message.". I have doubts regarding what should (if anything) be included in the dataset.
Please correct me; from what I understood what this option does is to dynamically (as if meant by the number of instances of the headers) allow signing header even if there are more than one instance of the header and adding an additional empty instance (just like to mean the end of this type of headers). What I am unable to correlate is the practical need of this dynamic signing (as what headers could have been repeated earlier can also get repeated later thus breaking the validity). It'll be helpful if someone can explain by say an example.
The thing that's confusing you is actually the whole point: oversigning is supposed to break the signature if that header gets added later. That breakage is the defense, not a side effect.
What oversigning does mechanically
Normally h= lists each header you sign once, and DKIM hashes the ones that exist. Oversigning lists a header name one more time than it actually appears. Per RFC 6376 section 5.4.2 a signer may name a header in h= even when it isn't there, and the verifier then treats that extra slot as the null string. So oversigning From does not sign a second From, it signs the statement "there is one From, and nothing after it."
Now the payoff. If someone adds a second instance of that header downstream, the verifier is recomputing a hash that was built assuming that slot was empty; the slot is no longer empty; the hashes do not match; DKIM fails. You have cryptographically forbidden the addition of that header.
The attack it stops (your example)
Take a message you legitimately signed with one From. Without oversigning, an attacker can take that intact, still-signed message and prepend a second From: [email protected] at the top. DKIM verifies the physically last From (your original, per 5.4.2), so the signature still passes and DMARC still passes on your domain, but most mail clients display the top From, which is the attacker's. You have lent your DKIM pass to a spoofed sender.
Oversign From and that stops working: the signature said "one From, no more", the second From breaks the hash, DKIM fails, and DMARC rejects it. That is the practical need you were looking for. RFC 6376 section 8.15 is the write-up of exactly this addition attack.
SignHeaders vs OversignHeaders
They are not the same thing. SignHeaders decides which headers go into h= at all. OversignHeaders adds the ones you list a second (null) time so additions are locked out. You typically sign a broad set and oversign the security-critical subset.
What to actually put there
Oversign the headers that carry identity or are shown to the user and should never legitimately gain a second instance after you sign: From above all (DMARC aligns to it), then Subject, Date, To, Cc, Reply-To, Sender, Message-ID, In-Reply-To, References, and the MIME set (MIME-Version, Content-Type, Content-Transfer-Encoding).
And this is the answer to your real doubt about headers being repeated later: only oversign headers that must stay singular end to end. Do not oversign headers that legitimate intermediaries add or rewrite. The classic footgun is a mailing list: lists add List-Id (and sometimes touch other headers), so if you oversign List-Id, every message you send through a list breaks its own DKIM signature. Lock down the immutable identity headers, and leave the ones a forwarder or list is allowed to modify alone.
