Of course you have control. You don't have to accept unencrypted communication. Just reject with a temporary fail and a message that says 'The use of STARTTLS is required for this recipient". If enough sites did this plain SMTP would disappear in almost no time flat.

Even with DANE most people use a third party (gmail, hotmail, yahoo or their ISP) to store their email on as ISP's block direct to customer emails.

No company can, in good faith, claim that they are not distributing confidential details to a third party if they send them in the clear via email.

All it verifies is that a card with a mag strip programmed with your data has been presented. That card could be library card, hotel door key ....

The messages are processed automatically and are not read by humans other than the recipient. They are reject or filtered to a "SPAM" folder. The expectation of privacy is still met. The ISP is processing the email for acceptance or rejection, it is not redirecting it to another party. Additionally the checks are being done on behalf of the recipient and can often be disabled by the recipient.

You mean the encrypted data streams. :-)

SMTP, IMAP, POP all support encrypted data streams. There really is no reason these days for email to be sent in the clear other than laziness.

With a telegram you have a telegraph operator who types up your message for you then sends it. With a postcard you have a sorter / deliverer who reads the address and sees the message even if it is not read. Neither process is fully automated.

With email you type up your own message and send it into a system that does not require human interaction to deliver the message. The only time a human other than the intended recipient sees a email is when there is a delivery error.

"Lift the buckle" is not the same as "push the button". Airplane seat belts have different mechanisms to most (not all) car seat belts and while you may use a car seat belt 600+ times a year, unless you are a frequent flyer you don't come anywhere close to that in a plane even going to the toilets. The message is telling the passengers that there is a different mechanism in the hope that it will save your life in the event of a survivable crash.

Which is basically down to lack of experience rather than actual gaps in protocol coverage.

Most ISP's are only now starting to ask "how do I do this". They should have been asking this question 7 to 8 years, if not longer, ago.

Actually it is utilisation. IPv4 ran out of addresses over a decade ago when NAT no longer became optional for the majority of users of the Internet. Ever since then we have been in stopgap mode. Unfortunately most users have never experience the real Internet when everyone can be both a producer and a consumer.

In most of the world you can use cryptography for authentication even if you can't use it for confidentiality.

Without cryptographically verified authentication you can't even verify the MX or A records are valid so you have nothing to verify against. It is only a matter of time, if they are not already, spoofing DNS responses to enable delivery of their messages.

It's perfectly possible to authenticate email with distributed senders. It just requires willingness to deploy the tools to do it. This includes updated clients. Whether that email is spam or not is a orthogonal matter.

MX records are for inbound traffic. SPF is for outbound traffic. Don't mix the two.

SPF is not a spam solution. Spammers can have legitimate SPF records.

SPF is design so that the recipient can reject forged emails without the blow back impacting the person whose email address is being forged. This only works if the published SPF records reflect reality.

Google could deliver IPTV and cut into the TV market as well. TV is digital these days. The analog cable plants are almost all gone.

DNSSEC was designed around real world constraints, not the mythical world where every resolver can talk to authoritative servers directly or only through trusted recursive servers. Yes, there are ISP that force you to use their name servers.

DNSSEC is designed to cope with untrusted authoritative servers. Most people don't have the resources to provide the servers necessary for fault tolerance. With DNSCurve you have to trust those operators to not change the data as any change they make can go undetected. With DNSSEC the worst they can do is reduce the effective number of name servers for the zone.

As for OpenDNS you still have to establish a trusted path to them.