Well, I might have not explained this properly, but what I meant was that if server-to-server SMTP started and negotiated encryption after issuing STARTTLS, but that ended up failing due to supported ciphers, that server should not retry again and ignore STARTTLS completely.
(BTW, it was a late night when I wrote the part you quoted, so I am not even sure now what I meant but the second bullet - most probably that it _should_ support same level of encryption)
If transmission was over unencrypted channel, I can see that in headers and decide how much I should trust this message accordingly, especially knowing that other side should be perfectly capable of good encryption.
When client submitted message - event if it made sure the connection was properly encrypted, it is now out of its control and he has to trust provider to deliver the message to other end over the best possible link... If Google or even Yahoo would refuse delivery (or acceptance) over SSLv3 and won't retry completely unencrypted, I feel that is better for me than FastMail just using weak cipher and call it a day.
I perfectly understand your choice, do not get me wrong! I am just thinking that if major providers chose to disable SSLv3 and you have couple of clients holding you up to this for some strange reason, I'd rather follow industry. Unless those clients are the main income producers
