[cm2187]

How did these committees think that optional, downgradable encryption was preferable to a standalone, encrypted only port (465)? Were they trying to save server ports, like if it was a precious resource? Any design decision I have seen regarding email since 2000 defies common sense. Like I heard most SMTP implementations do not validate certificates. What good is an unvalidated certificate? SPF is treated as indicative only or ignored.

We are managing to replace http1.1 with http2, it will take time but it is on the way. I am not even aware that an actual SMTP2 draft protocol that would solve all these design flaws (unverified sender, unencrypted).

And SMTP has a benefit http didn’t have. Most people access their emails through webmails, smartphones or enterprise outlook/exchange servers. For webmails and exchange only the server needs to be updated, and for smartphones, their short life ensures that older versions are pretty much all retired within 5 years. In addition, a handful of big players (google yahoo apple msft) have such a concentration of recipient accounts (retail users) that they can force a change on the market with the threat of your mail being classified as junk by them. So we could achieve a pretty quick transition.

[lvh]

Apparently 465 is only for mail submission, not MTA-MTA -- but of course that still leaves the obvious questions of a) why? b) if it must be a different port, why not make that TLS-only?

[JdeBP]

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

* https://news.ycombinator.com/item?id=10405864

[cm2187]

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 necessarily a need to go through an smtp relay (my mail server doesn't)

- failover mail servers should check spf on incoming email and then have a trusted relationship with the primary server so that spf isn't enforced when the failover delivers to the primary (that's the way my mail server works)

- spf uses DNS. So what?

- ISP lock-in. If you control the domain/DNS entries, there is no lock in. If you don't, then you are already locked in anyway.

- doesn't allow dynamic IPs. I'd argue that 1) it is a good thing 2) it's not really the case, you can specify a domain in spf, and this domain can be a dyndns style domain with a short lived TTL resolving to your current dynamic ip. And in theory you could also dynamically update your spf as your ip changes with a short TTL (like a dyndns-style entry).

[edit] and actually what is going to kill you with a dynamic IP is not so much spf than the fact that the reverse dns of that IP won't resolve to your domain which is a big spam red flag for most smtp servers.

[kilburn]

> 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 [e-mail] 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.

[cm2187]

> 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.

[kilburn]

> I'd argue this is the fair and correct behavior.

A behavior that breaks how the mail system has been working since forever, and that people expect and use all the time.

It may not be right, but it is used and not even the big players (such as gmail) are willing to break it (hence why gmail actually tells other admins to use pre-delivery forwards disregarding SPF, but respecting DKIM wich is broken if you use post-delivery aliases) [1].

[1] https://support.google.com/mail/answer/175365?hl=en

> Sounds like a misconfiguration.

A misconfiguration you cannot fix (because it is on the receiver end, not on your end). But the client pays you for the service, and understandably asks you for a solution. What would you tell them?

I understand your points, and mostly agree with them. However, this approach only works in an ideal world where users understand that e-mail should have some limitations it hasn't had for the last 30 years, and all administrators are "good citizens" (they know their stuff, acknowledge their issues and work to quickly fix them).

The real world is different: clients will demand solutions, and other admins will oftentimes be either ignorant, powerless or even adversarial.

[detaro]

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.