[DKIM-SECURITY] Module is way, way too simplistic and has big flaws

Here are some features that would help:

• Setting what headers will be signed (in addition to the body).

• Being able to choose match-modes between strict and loose, the latter being ok with minor modifications from other MTA relays and such and is sometimes preferable.

• It defaults to test mode, which is WRONG. It defeats the entire purpose of DKIM. The "t=y" flag should only be enabled if you want to be notified about errors (the spec says that domains with that flag are requesting deployment help and feedback), and it signals to the world "it doesn't matter if the signature doesn't match since we are still in the test phase".

• The better mode is "t=s" which locks it down so that the key is strictly verified against the exact domain of the sender. You can't mismatch and send an email from @foo.bar.baz.com and sign it with a @bar.baz.com key in that mode.

• [DNS issue] The DKIM key is not added when you create sub-servers UNLESS you tell those sub-servers to create their brand new, own DNS zone. The Key is added perfectly to all master/main servers, of course.

• The previous point is serious, because cat /etc/mail/dkim-milter/keys/keylist shows it's enabled for the subdomains even though they lack the key record in their DNS, meaning that outgoing emails will fail validation since no key can be found. (The solution is of course to always create sub-domains as their own, new master DNS zone)

• The "DNS records for additional domains" field lies. It says "k=rsa, t=y, p=" but the actual record that's inserted in domains is "v=DKIM1, k=rsa, r=postmaster, t=y, p=" - this needs fixing.

• Moreover, it lists a DomainKey (deprecated) policy entry. We should not be using DomainKeys anymore, so the policy entry (the one with "o=-") should not be listed in the box.

• The default key length is 2048 bits, but like I mentioned in another ticket this breaks BIND since Virtualmin doesn't write long DNS TXT entries properly.

• The default key length of 2048 bits is bad. It's excessive. It's like 20x slower, for almost zero benefit. Security researchers have estimated that it would take a year of processing time on a $200 million dollar machine to brute force a 1024 bit key.

• The fact that 2048 bit keys are 20x slower (or more) than 1024 bit keys mean that it puts lots of load on the sending and receiving servers. Instead of checking a key in milliseconds, it may take 200 milliseconds.

• Keys should be rotated yearly anyway, so there is zero benefit to going over 1024 bit today. Just harm. Like the DNS length issue, and slowness.

• The longer 2048 bit keys also slow down the DNS query since every client is forced to redo the request via TCP rather than UDP, becuase the UDP reply can't fit the whole key.

So, recap:

• Do not create the deprecated _domainkey policy entry
• Make sure the DKIM key is added to every domain even when they are children of parent zones, since messages are always signed (so key MUST be available in the zone)
• Add an option for key size which defaults to 1024 bit and can optionally be set to 2048 bit with a warning that it's SLOW and harms the recipient systems of your messages.
• Add a "test mode" toggle which switches between "t=y" (test) and "t=s" (lockdown, production use)
• Tweak the DNS editing module so it supports > 255 character TXT entries properly

Anyway, here are my temporary patches to make DKIM better until official fixes: