The original post, which started all this discussion was about your MX SMTP servers and not about your client submission servers - those are good and anyone can check themselves easily:
This command should fail to connect. More tests can be done at https://pentest-tools.com/network-vu...er-online-nmap

But let's go back to MX SMTP servers - the is no doubt that all servers support unencrypted connection, however I state that IF connection is encrypted, it should not:

• Allow fall back to unencrypted
• Support the same encryption level as client SMTP sevrer

That's what FastMail competitors do.
And that marketing blurb was not relevant to the issue.

I would understand if ChinaLamb would respond with clear explanation that SSLv3 with weak ciphers is only for server-to-server transport and is set up that way to maximize compatibility.
But no, ChinaLamb ended up saying that poster's fault in not understanding "marketing speech":
Very unprofessional, if you ask me.
And yes, FastMail is different - providing less secure SMTP transport options than others - in order to be more compatible... But why? To get more spam? Because those broken MX SMTP servers out there are more prone to be hacked and start sending spam...

I'm not commenting on the opinions of people who aren't FastMail staff, their opinions are their own.

I will comment on this opinion though:

"IF connection is encrypted it should not allow fall back to unencrypted". That is meaningless. An active attacker can just remove the capability strings from the connection and make it appear that the destination server doesn't support encryption. You can't just "not allow fall back unencrypted" unless you don't offer unencrypted at all, which is why we don't offer unencrypted for IMAP/POP.

Likewise, the client can choose what level of security it's willing to require before it will send the email down the connection, so even if you offer less secure options, the client can choose not to continue with the SMTP transaction unless it got to a security level it's happy with.

I'd love to be able to turn off all the lower security options, but people want to be able to receive email from arbitrary senders. Our competitors may just fall back to plaintext, fine, but there's no actual security benefit to plaintext over deprecated ciphers - it's security theatre either way. Neither choice is objectively better.

The actual ciphers offered/used are useful datapoints for spam scanning, but rejecting the message outright is a bad user experience.

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 :)

Obviously, senders can refuse to deliver based on whatever combination of rules they want. The point is that it doesn't matter what FastMail advertises.

I repeat. _it_does_not_matter_. Because an active proxy can rewrite that however it likes, offering SSLv3 only, or offering plaintext only. So the only thing that will stop those being used by an active attacker is senders refusing to send at all in those cases.

We probably will follow the industry pretty soon. I'd love to be able to lead the industry in these cases, but the simple fact is that we're not big enough to unilaterally stop accepting SSLv3. Now that Google have done so we probably can too and just tell out customers to tell their senders to upgrade:

http://www.infoworld.com/article/307...ers-gmail.html

(June 16 apparently)

You have probably read the explanation of why we only support the SSL/TLS ports and not the StartTLS ports for IMAP/POP to avoid clients downgrading to plaintext and sending their passwords across the wire in the clear. We can reject that, but it doesn't stop the password having already been sent! In the theory vs practice world, not listening on port 143 provides better security, but not offering SSLv3 is just wishful thinking while plaintext fallback is a thing.

Of course we haven't even started addressing the other elephant in the room, which is that nobody verifies client certificates for SMTP, so even if we enforce that the connection to our servers users the latest and greatest algorithms, we don't know who the other endpoint is. They could be an active proxy offering plaintext back to the real sender and we'd never know.

The only thing active proxy should be able to do is to remove STARTTLS... If MX _client_ is verifying certificate properly, someone has to steal signed certificate to impersonate _server_ endpoint. Server won't know for sure who is talking to it, unfortunately reverse DNS is not an authentication mechanism...

I am glad, you will go with the flow. And I have no issue with offering only IMAPS/POPS - this is right thing to do.

As for client certificates - I have some reservations... headaches with implementation usually outweigh benefits :( Biggest issues I deal with are certificate expiration and correct trust chain...

Thanks a lot for your clarifications, appreciate your patience!

It's actually worse than that. Forward DNS isn't an authentication mechanism either.

If I type 'https://www.fastmail.com' then the endpoint I connect to via DNS needs to response with a signed certificate for www.fastmail.com or *.fastmail.com which is signed by a trusted CA. So far so good. Someone can poison the DNS, but they still have to proxy the packets to a real server that is has the correct certificates on it.

If I type 'mailto:bob@fastmail.com' into my mail client, the active DNS intercept can return:

fastmail.com. IN MX 5 evilhost.evilsite.com

and present a perfectly validly signed certificate for evilsite.com signed by any trusted CA, and the message will be sent to them. SMTP really isn't safe against an active man-in-the-middle attack which can poison DNS. But I'm sure you already know all that.

On the plus side, most places log which MX they actually connected to, so it's possible to know that you were attacked after the fact:

2016-10-17T00:45:43.226981-04:00 gateway1 postfix-out/smtp[1246889]: Trusted TLS connection established to gmail-smtp-in.l.google.com[173.194.204.26]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
2016-10-17T00:45:43.624653-04:00 gateway1 postfix-out/smtp[1246889]: 189D020762: to=<..myaddress..>, relay=gmail-smtp-in.l.google.com[173.194.204.26]:25, delay=0.53, delays=0.05/0/0.15/0.33, dsn=2.0.0, status=sent (250 2.0.0 OK 1476679543 r12si16909167qke.70 - gsmtp)


Anyway, what I'm saying is that security is a chain, and offering SSLv3 is nowhere near the weakest link in the SMTP transaction, which is why I'm a bit meh about upgrading that particular link with a titanium plated version while there are other, weaker, links involved in all the plausible threat models.

Yeah, you are correct... I stopped caring over SMTP servers for some time already and forgot that MX record is also resolved indirectly, like this. But shouldn't DNSSEC take care of this? And better analysis of SPF - in order to hide itself complitely, active proxy would have to spoof both sides of the transport connection...

But look - my point from the beginning was this - I, personally, don't trust mail transport encryption - because of all discussed above. If I have to, I'll encrypt message itself - PGP or S/MIME...

What I care is a reputation of the provider I use - if there is a widely available tool, which shows that FastMail is inferior - that's a bad sign... And needs to be fixed, even if it does not help from technical point of view that much...

I guess your point, which is difficult to argue with, is that perception is more important than reality when it comes to marketing. When the wider Internet is flawed such that (short of end-to-end encryption) security cannot be guaranteed, many less technically sophisticated users will look at simple reports that say this cipher is unsafe against attacks by nation states, and fail to understand that no cipher is safe against nation states because MitM attacks render the whole issue moot.

I never said that "that perception is more important than reality when it comes to marketing". Importance is very relative and depends on the target audience. But I am not a marketer :)

Guess, we beat this topic to the death now.

Speaking as a total (uneducated) neophyte (in regard to the topic under discussion) I would like to say that I have totally enjoyed reading this thread - it would be sad if it ended too soon. Good (educated) reading is hard to come by, these days...

Firefox Nightly enables support for FIDO U2F Security Keys
Yubico Blog, Sep 22

Finally!!
Integrated U2F support for the mozilla masses.
We should see it in the next FireFox release.