"We use the provided bundle file to.."

[jult]

What 'provided bundle file' ? There has not been any mention of a bundle file, let alone seeing it 'provided' by anyone or anything.

Good grief, what a PITA this whole DANE thing is to set up. Am I to grasp that each time I generate a new cert (i.e. LetsEncrypt), I would also have to recreate the DANE records for the insanely complex DNS entries?
If so, this means that at/during every new DANE DNS records change, the mail is vulnerable to not being accepted because the DANE checks fail. Plus, more importantly; All this was to prevent what exactly? MITM attacks? This DNS propagation could take 48 hours, globally, until they are fully live. 48 hours in which the MITM attacks mitigation is null and void. What idiot designed this?

Because basically what you do is: Look for when the certs expire, find out how long DNS propagation takes, hope it takes long enough (or offer a non-propagated DNS to your victim for a MITM during SMTP auth) et voila. Useless.

[xzenor]

While I agree on the usefulness (or the lack thereof) of DANE, it's not as horrible as you think. If I understand it correctly you can also use the root or intermediate certificate by adjusting the 'usage' switch. This should fix the Let's Encrypt problem. The RFC also goes a bit deeper into the rollover of certificates. This kinda works the same as with DNSSEC where you already publish the new one next to the old one to let it propagate and then change the certificate on the mail service.

It's still just a patch job to attempt to secure a system that was built without security in mind. Just don't use email for secure data imho.

One thing to keep in mind though is that the people from this GitHub account did not invent DANE. They're just trying to translate the RFC to something human readable. So while I personally completely understand your aggression against DANE, this may not be the best place to express it.