Does anybody that runs a large mail system have any stats about how much mail is delivered over SSLv2 and SSLv3 nowadays?
STARTTLS Everywhere
71–80 of 106 posts
Re: STARTTLS Everywhere
#72States "Couldn't connect to grepular.com. We couldn't find any MX records for grepular.com! Did you make a typo or enter the wrong email domain? Make sure to enter the part of your email address after the @!"
Then proceeds to show results for the MX anyway. With a single error: "Does not use a secure TLS version Error: Could not establish connection with hostname %!s(MISSING)"
Seems a bit broken to me.
Re: STARTTLS Everywhere
#73Earlier quoted context omitted.
The same has been pointed out about Web browsers using SRV DNS lookups to find servers. * https://news.ycombinator.com/item?id=17395600 SPF, of course, should be used everywhere so that we reach the point of complete balkanization and collapse, and people realize that we can (and in fact in some ways already have ) switch wholesale to different systems, faster. (-: * http://jdebp.eu./FGA/smtp-spf-is-harmful.html * ht…
Not that I think that SPF is the ultimate solution (it is merely a thin layer of lipstick on the pig) but I don't agree with many of the assertion of your "spf is harmful" link. - pre-delivery forwarding servers just need to be added to spf. If you use random third party smtp relays, then this is precisely what spf is trying to avoid. - the way internal servers implement aliases is their problem, there is not necessa…
> pre-delivery forwarding servers just need to be added to spf. If you use random third party smtp relays, then this is precisely what spf is trying to avoid.
The huge problem here is "forward all e-mail I receive to my gmail account" or similar. If you do that pre-delivery, you break SPF. If you do it post-delivery, gmail makes you responsible for any junk that gets through. If you make your filters harsher, the user complaints some e-mails are lost. What is your solution to this problem?
> the way internal servers implement aliases is their problem, there is not necessarily a need to go through an smtp relay (my mail server doesn't)
Now you send an e-mail to contact@yourbank.tld and the message is rejected because of your SPF policy and their usage of internal relays. You can (a) fight the corporate shitshow to get someone to fix the bank's relay; or (b) relax your SPF policy. You may be willing to pursue (a), but a company that sells e-mail services to thousands of clients just cannot enter those fights and still be economically viable.
Don't get me wrong. I use SPF (DMARC actually) on my personal server and it actually helps (as a low volume sender), but the moderate volume senders' problems are different from those of personal e-mail servers, and SPF works much worse there.
Re: STARTTLS Everywhere
#74Earlier quoted context omitted.
Not that I think that SPF is the ultimate solution (it is merely a thin layer of lipstick on the pig) but I don't agree with many of the assertion of your "spf is harmful" link. - pre-delivery forwarding servers just need to be added to spf. If you use random third party smtp relays, then this is precisely what spf is trying to avoid. - the way internal servers implement aliases is their problem, there is not necessa…
> pre-delivery forwarding servers just need to be added to spf. If you use random third party smtp relays, then this is precisely what spf is trying to avoid. The huge problem here is "forward all e-mail I receive to my gmail account" or similar. If you do that pre-delivery, you break SPF. If you do it post-delivery, gmail makes you responsible for any junk that gets through. If you make your filters harsher, the use…
> gmail makes you responsible for any junk that gets through
I'd argue this is the fair and correct behavior. Effectively you created a kind of open relay server. Since you accept external traffic, you should be filtering for spam there.
> the message is rejected because of your SPF policy and their usage of internal relays
I'd assume that if it is an internal relay server, then it shouldn't be checking for spf internally. Only the server receiving incoming external traffic should check spf. Sounds like a misconfiguration.
Re: STARTTLS Everywhere
#75Earlier quoted context omitted.
The STARTTLS vulnerability to downgrade attacks is a significant downside that port 465 doesn't have (if using modern TLS protocols at least). My opinion is that perhaps the severity of the STARTTLS downgrade attack wasn't that much considered when port 465 was deprecated.
The only (weak) argument I can find is that since servers that had a port 465 open also had to keep a port 25 open for compatibility, you could perform the same downgrade attack by blocking connections to port 465, which would result in a submission to the port 25. But that's a "if it's broken let's make sure it remains broken" kind of argument.
Yes - it's a weak argument, and one that's probably been debunked by looking the way https lifted off recently. My view is if port 465 was still around today, it would probably get the same level of attention as port 443 has. We could have been at a stage where port 25 could be made intentionally unavailable (same way we move browsers from http to https) and everything forced to 465. Email agent developers would be forced to update their practices as well, no email should be sent over plaintext. At present, there is no good way to tell your clients you're not accepting plaintext. STARTTS is from a world where 99% of emails were plaintext.
Re: STARTTLS Everywhere
#76Earlier quoted context omitted.
Port 465 is unnecessary once STARTTLS was invented. It has exactly the same upside / downside but it wastes an entire TCP port and an entire RTT plus maybe a timeout to signal (non-)availability. So it makes sense to deprecate this use of port 465 and just tell people to use STARTTLS.
The STARTTLS vulnerability to downgrade attacks is a significant downside that port 465 doesn't have (if using modern TLS protocols at least). My opinion is that perhaps the severity of the STARTTLS downgrade attack wasn't that much considered when port 465 was deprecated.
I wrote "It has exactly the same upside / downside" and yet almost immediately I get a reply in which the author with no self-reflection has imagined there are additional downsides to STARTTLS.
As others have explained an on-path adversary who'd be able to rewrite packets in order to stop STARTTLS can even more trivially block port 465 altogether. In fact cheap appliances can do the latter but can't do the former, so if anything STARTTLS very slightly improves this.
If you are imagining "Well I could have a policy of only using port 465" well, sure, but you could just as easily have a policy of requiring STARTTLS. In both cases an adversary can deny you, and your only options are to re-think your policy or give up and not deliver email.
Re: STARTTLS Everywhere
#77It's worth also mentioning MTA-STS [1], currently a draft. It provides a mechanism for domains to declare a STARTTLS requirement via a file at /.well-known/mta-sts.txt" rel="nofollow">https:// /.well-known/mta-sts.txt . It's backwards compatible and opt-in. There seems to be some testing already going on [2]. [1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-21 [2] https://mta-sts.gmail.com/.well-known/mta-sts.t…
This is interesting, I have been wondering for a while if I could disable plaintext email delivery on port 25 and just leave encrypted submission on port 465.. Would I be losing mail ?
Gmail says 89% of inbound email is encrypted (up from 60% 2 years ago). So theoretically you'd lose 11% of your mail. https://transparencyreport.google.com/safer-email/overview?h...
Re: STARTTLS Everywhere
#78Earlier quoted context omitted.
The only (weak) argument I can find is that since servers that had a port 465 open also had to keep a port 25 open for compatibility, you could perform the same downgrade attack by blocking connections to port 465, which would result in a submission to the port 25. But that's a "if it's broken let's make sure it remains broken" kind of argument.
Yes - it's a weak argument, and one that's probably been debunked by looking the way https lifted off recently. My view is if port 465 was still around today, it would probably get the same level of attention as port 443 has. We could have been at a stage where port 25 could be made intentionally unavailable (same way we move browsers from http to https) and everything forced to 465. Email agent developers would be f…
You've confused the submission port (which is usually TLS encrypted on 587) with SMTP relay (done via port 25 with optional STARTTLS)
It's OK, lots of people don't know about this. Really the only problem is that you've assumed since you know nothing about this you're an expert, that'd be Dunning-Kruger or a related effect at work.
For submission it really can work to upgrade end user mail agent software. We're a long way from useful encryption capable agents being ubiquitous, but we've made progress and most popular systems today ship with such a client. These systems also use TLS directly for IMAP (to receive email) and can share a lot of logic across the two systems, so that's nice. In maybe a decade we'll be where HTTPS is today. For submission.
What distinguishes a submission port is that it's authenticated. You can only send email via the submission server as Alice if you prove to the submission server that you're Alice.
But SMTPS (obsolete SMTP over TLS on port 465) and the STARTTLS SMTP (on port 25) are for email relay. Authentication makes no sense in this scenario because the relays are neither sender nor recipient, the transmitting relay can't prove that it's Alice, and the receiving relay can't prove that it is Bob, because they're not, they are merely relays.
These are servers, so they upgrade much more slowly (often only on hardware replacement) and the priority is reliability of delivery, not security, if your proposed solution drops 1% of email on the floor that's far too much and nobody would adopt it.
Hence the situation we have today, and hence STARTTLS Everywhere. Your imagined alternate universe makes no sense except because you've misunderstood how email works.
Re: STARTTLS Everywhere
#79Since proper email transport encryption is finally getting some momentum with DANE and MTA-STS, I'm surprised that STARTTLS Everywhere doesn't mention them.
DANE is being recommended (mandated?) by the European Union, and is on the rise. MTA-STS is backed by Gmail, Microsoft and many others, which is likely to give it traction.
Re: STARTTLS Everywhere
#80Earlier quoted context omitted.
> pre-delivery forwarding servers just need to be added to spf. If you use random third party smtp relays, then this is precisely what spf is trying to avoid. The huge problem here is "forward all e-mail I receive to my gmail account" or similar. If you do that pre-delivery, you break SPF. If you do it post-delivery, gmail makes you responsible for any junk that gets through. If you make your filters harsher, the use…
> gmail makes you responsible for any junk that gets through I'd argue this is the fair and correct behavior. Effectively you created a kind of open relay server. Since you accept external traffic, you should be filtering for spam there. > the message is rejected because of your SPF policy and their usage of internal relays I'd assume that if it is an internal relay server, then it shouldn't be checking for spf inter…
I don't think it makes sense to classify an individually set-up, per-account redirect an "open relay server". It can't be used to do anything the user didn't intend.
Maybe it would help to allow users to whitelist such cases.