You mean browsers actually fall back to non-perfect-forward-secrecy? They even have the option of doing that? That's interesting if true. Ideally it should be enforced by the server, and if the browser can't support it, then the browser can't see the webpage.
You can only support forward secure cipher suits. This will result in rejected connections as you suggested.
Lavabit doesn't do this, they support non-forward secure ones. Worse, they don't offer a cipher-suit order preference and the cipher suits they offer are actually pretty shitty (no ECDH_ECDSA, 1024bit DHE).
The way they have it configured now means anyone using the default browser on windows(IE) or OSX(Safari) doesn't end up negotiating a forward secure session. Chrome and Firefox do end up being forward secure. See SSL Lab's test result here[0]
They support
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ideally, Microsoft, Google, Apple, and Firefox would gang up and all disable ciphersuites lacking DHE/ECDHE in their current browsers. Short of that, one browser disabling them would be viewed as "broken" and would lose marketshare.
Well, the browsers could disable non PFS ciphers by default. When a site doesn't match any PFS cipher list, show a pop-up with a way to add an exception for the site.
Much more graceful than a complete switch-over and doesn't require co-ordination from other vendors.
The browser and the server both have lists of ciphers they will permit. Any cipher shared between both endpoints can be used.
Browsers permit connecting with non-FS ciphers because there are many many servers out there with cipher lists based on older versions of SSL/TLS, and users would complain if they upgraded Firefox and couldn't connect to their bank.
Servers permit connecting with non-FS ciphers because excluding them would block users with older browsers from accessing the server, and give them a confusing unhelpful error page.
It is possible for the server owner to permit only FS ciphers (and therefore impose a strict version requirement on browssers).
If you cared about security and knew enough to check that, you probably knew enough not to trust server side crypto and were using PGP or S/MIME on top of it or using OTR instead of email for secure conversations.
That aside, this still leaves the very important question of SMTP traffic.
