FTP is an absolutely bonkers protocol. I’ve written lengthy posts in here in the past detailing why that protocol needs to die.

Email is another clusterfuck of a protocol (well, several protocols) that barely functions despite dozens of modern pseudo-standards plastered over it. I’ve written extensively about that too.

DNS is frequently the source of amplification DDoS attacks. It’s another protocol that made sense once upon a time but has struggled to keep pace with modern advancements in technology

IRC is probably the best of the bunch here but even that has struggled to keep pace and can be subject to undocumented behaviours (like line length).

…and these are the protocols still in use. The ones replaced by HTTP were either crazier or over simplistic that they offered nothing over HTTP.

I’ve written my own clients for every one of those examples and had to deal with the pains of their protocols. I’ve also written my own web browser. And while HTTP has some warts too, I’d take that over FTP and SMTP any day of the week.

> Email is another clusterfuck of a protocol (well, several protocols) that barely functions despite dozens of modern pseudo-standards plastered over it. I’ve written extensively about that too.

SMTP is one of last of decentralized open communication protocols that is still widely used by business. It evolved over time, gained some additions and stayed alive. The biggest issue I have with e-mail nowadays is companies like Microsoft and Google acting like they go out of their way to break protocols and deliver less and less messages from perfectly well working but decentralized sources.

Microsoft is especially bad of the two, with years-long tradition of acting against standards (Outlook Express connecting to recipients' MX, cloud offering accepting messages for delivery and never delivering them [1] etc). Google, I believe, as soon as they find a better way to get hold on user's invoices and receipts, will teach their users that they should use something else instead.

Stating that standard barely functions just because anti-privacy corporations only pretend to use standards in way there were intended, but concentrate on breaking them, is not how I would describe current state of e-mail-related stuff.

[1] https://news.ycombinator.com/item?id=27980192

The "decentralization" of SMTP comes from the high level architecture of store-and-forward. It has very little to do with the protocol, which could be expressed more effectively and cleanly on HTTP2 or HTTP3 (it won't be, but should) without risking any of its "openness".

Decentralization was not a quest when those protocols were created. It pretty much became "a thing" with blockchains. It previously... just "was".

It started "not being anymore" with corporations - and once again I bow before Microsoft and Google - using less and less lube over time when telling their own clients what their role is at the ecosystem.

I will absolutely fight any attempt at calling e-mail protocols broken just because a corporations can't figure out their revenue around it.

You’re conflating a number of issues. We are strictly talking about technical specifications. Not about who owns what nor even arguing that everything should be centralised. In fact it is technically possible to create a better alternative to SMTP while still satisfying all of the non-technical requirements you’ve outlined too. You could even drop feed that new protocol into existence the same way we’ve seen IPv6 creep in parallel to IPv4, albeit it would probably take 20 years to do so.

And this isn’t even touching on the problems with IMAP and the insanity that POP3 is even still a thing.

You are right - I may have went too far into blame assigning while explaining too little of my viewpoit. In my opinion e-mail protocols aren't but e-mail ecosystem is getting increasingly broken. Sure, SMTPv2 is _technically_ possible but I don't think it would be allowed to grow, mature and exist as a standard.

Last time I attempted setting up messaging accounts with beforementioned companies, it wasn't possible to use Mutt or bare Thunderbird - one had to use client software allowing some kind of RCE to set up access to those services. Add Google's bubbling[0] and Microsoft's repeated mail losing, and we no longer really have globally functional e-mail based on standards.

When some of the biggest actors don't follow rules describing delivery without proposing changes - yes - e-mail is being broken but not because protocols underneath are broken. It's because people trust these companies and possibly don't know that they may be victims of careful information filtering.

I have done some e-mail - related work for hosting companies in the past. For some years now, POP3 is not really a thing. It exists, it is being set up by mistake from time to time but the number of POP3 users compared to IMAP users was barely noticeable and I don't think it grew. I'm afraid to ask what your issues with IMAP are...

[0] I suspect that Google bubbles its e-mail customers just like its search users. Most non-technical people I know treat "spam" folder like it would literally burn their fingers upon touching. They act similarly, like trained to only look inside there when not seeing awaited messages in the inbox. Google delivering perfectly fine messages straight into "spam" folder has comparable results to Microsoft losing/destroying their customers' mail.

Email protocols are broken because they are bad 1990s protocols that haven't benefited from 20 years of systems learning about building protocols. I don't much care who does or doesn't have a hard time monetizing them.

It’s even older than that. It was originally released in the early 80s but is based on mail transfer protocols developed in the 70s.

Email dates from an era when it was safe to trust people connecting to your server because everyone knew those individuals personally.

That methodology hasn’t scaled in 30 years.

> Email protocols are broken because they are bad 1990s protocols (...)

I see arguments for "non-modern" not "broken". Some wines aging better doesn't necessarily mean that others deteriorate.

I've done POP3 and SMTP and they didn't seem TOO bad but those were just toy implementations which didn't have to work in the real world and I gather things have gotten pretty complex and ugly since then. What would you suggest to replace e-mail while retaining its flexibility?

SMTP doesn’t really have a universally agreed way of handling authentication, error handling nor even encryption. There are several standards floating about, many of which are little more than pseudo-standards.

> What would you suggest to replace e-mail while retaining its flexibility?

There’s no reason why we cannot redesign the email paradigm around a totally new protocol. The problem isn’t that’s it’s technically difficult, it’s that SMTP is too prevalent now. It would take someone like Google abusing their market share so bring in a successor.

Also any replacement would need to be at a protocol level. A lot of the attempts I’ve seen have also tried to modernise the experience as well (like Google Wave) but the reason email is successful is because it is familiar.

As far as I can see, jmap only provides means to upload email to your email provider, it doesn't actually tell how that email ends up from one email provider to another, which is what SMTP does.

Granted it's already nicer for clients not to need to configure SMTP to begin with.

Yes, one confusing aspect of SMTP is that there is a server-server part (listening on port 25) and a client-server part (465 or so, usually authenticated). I haven't dug in-depth, so maybe they are exactly the same protocol though.

Acessing port 25 of server is usually blocked by ISPs as a way to prevent spam.

The difference in ports is due to SSL/TLS expected to be automatically applied on 465 iirc like 80/443 for HTTP(S) (you can also encrypt 25 by issuing STARTTLS after setting up a connection but it's not the default and might fail I think).

Authentication with mail is separate, usually to allow for relaying whilst anyone can usually drop emails IFF your server is the destination.

Confusing and needlessly complex? Yep. Natural result as of uncontrolled evolution? Yep.

One of the big mistakes with the design of IMAP was that there wasn't a standard Out-Box where a client could rely on the IMAP server for sending the email. I'd have loved to see a world where mail clients only had to implement IMAP and nothing else.

You might like TMTP from the mnm open source project (my work).

OK, I'll bite.

finger was conceived in a time and environment where you would reasonably assume a lot of things which stopped being true a long time ago.

many users per machine/users actually logged in to that machine/users being in walkable distance or in the same building/no compartmentalization, i.e. your demon has access to every users' home directory

and that's just the top of my head.

if you see finger as "everyone has a place to store a message and people can read it" then yes, you might say it wasn't worse than HTTP - but I think the plan feature wasn't even the original intention, it was more "is person X at their desk right now?".

So all features aside, it has so many assumptions baked in, I'd have to think hard how to replicate it in a modern way for a company and still fit the protocol.

I'm not sure I 100% agree with the protocol being silly (merely not great, BUT it's been years since I read the RFC - it's short, you should), it's kinda simply plain text with some wonky hostname shenanigans, but the whole concept hasn't aged well. But that is if you completely ignore anything about security (see what I wrote above) and privacy.

The way I read it - finger protocol is a small rusty bike; whereas http by now is a fancy sports car. (Heck if we are talking http/2 or 3 it’s a damn flying car at that)

We now all go about our daily bakery shopping in the fancy sports car instead of a small rusty bike.

And people have differing opinions whether this is the best timeline to have...

I don't think that analogy holds. Let's assume you can still publish a perfectly fine (for 2021) web page with strict HTTP/1.1 - I think you can. It's very flexible and unchanged since its publication.

Finger on the other hand is would be a very narrow API to for a certain service without ANY of the flexibility of HTTP. No custom headers, no Basic Auth, not even the difference between GET and POST.

So yeah, maybe the original comparison between finger and http is already flawed, but unless HTTP/2 gives you something that HTTP/1.1 can't do then HTTP/1.1 is still perfectly valid, and probably will be in 10 years, at least for low-traffic situations. (finger should be reaaally low-traffic in comparison).

> Finger on the other hand is would be a very narrow API to for a certain service without ANY of the flexibility of HTTP.

That is the point. The flexibility is not free. Every conditional doubles the number of possible execution flows. This brings complexity. To some extent it is mitigated by the economies of scale because now everyone uses HTTP for something, so collectively we get that more complex code more polished. But there is no such thing as the bug free code - so every participant will have to deal with patch cycle and generally preventing bitrot.

For a small well bounded custom protocol which solves a well defined specific use case, one can hope to write a dependency-free implementation that can be tested and work well enough and left alone.

I recently was at an event with a few thousand wifi devices.

About a third of the internet traffic was updates..

No disagreement here, but this was about flexibility, not an absolute judgement of how far-reaching a protocol must be.

I think I like the idea of a "spec" inside the same "protocol" more. For example if you understand HTTP you can quickly reason about any spec of a REST API that's done with JSON payloads without caring for the HTTP wrapper layer, just as you don't care for TCP around it.

tptacek’s original comment was amounting to “finger protocol is strictly worse than http” - which reads quite as an absolute judgement.

Yeah, reusability and layering of engineering knowledge is useful - it makes dealing with complexity easier.

But it also makes it easier to build complexity without spending thinking of a simpler solutions. Because time to market.

And thus we have exhibits at https://mobile.twitter.com/internetofshit

Imagine if we were stuck in a world with a large bloc of users running MSIE6 regularly accessed web servers running 40-bit SSL2. Neither clients nor servers ever bother updating, because it still works for them.

That's essentially where every other protocol is. HTTP gets all the energy, active development, updates regularly rolled out. Meanwhile if you tried to make, say, FTP more rational by transmitting data over the control connection, nobody would be able to use it since all the servers are still running 25 year old wuftpd with the minimal patches to not get pwned and they have no interest in updating (if they even remember the servers exist).

Personally I think we've lost something valuable when only one protocol exists, but I'm one of those Luddites who still reads email with Thunderbird so what do I know.

The burden of proof is always on the person making a claim. I've made no claim on this subject. I haven't even entirely formed my opinion on this and am not even playing Devil's advocate. The point of my post was to try to improve the quality of the discussion here. Unsupported random opinions aren't generally relevant to strangers.

Unsupported random opinions are the lifeblood of internet forums, not that the comment was really that much of an unsupported random opinion. Strangers do not owe you presentation of their views to your exacting specifications. It's perfectly fine to be confused by things they say and it's perfectly fine to ask them what they meant.

What's lame and actually damages discussion is haranguing people over things they've said you can't make good sense of. That's not curious conversation, it's not really much of a conversation at all.

Completely agree. Also dismissing a post as 'stupid' does not quite sound good to me. I mean, probably we have better arguments to dismiss a particular post!

This has become a meta-debate, but I'd argue that the burden of proof is on anyone who wants something. If the thing you want is to get to the bottom of a question, then it's your own desire which has imposed that burden on you.

If you want something, it would be a shame if you didn't get it because an internet proponent failed to detail their arguments.

If you want me to believe something, it's up to you to convince me, otherwise I have no obligation to believe it based on what you've said. It doesn't mean I have or don't have an obligation to believe it in general, only that I do not based on what you said. This is all I meant. That someone should look into something they're interested in is orthogonal to burden of proof. One can still look into something while being unconvinced by something because someone didn't give an argument. It's only a judgement that their contribution is not useful in the investigation and is no indication that the investigation does or doesn't continue despite that.

Nobody has any obligations to prove anything here; that's not the premise of this space. You'd have more luck extracting clarifications from me if you either (a) wrote more civilly or (b) directly challenged what I wrote with some kind of rebuttal. You've instead chosen the least productive rhetorical path.

Nobody has any obligations to prove anything, only if they want to convince anyone of anything.

What do you think is uncivil about accurately characterizing your post?

I have no interest in challenging what you said. As I said, I don't necessarily disagree. I just think throwing out unjustified opinions isn't useful or interesting and it would be better if you had said why you think what you do.

It sounds like you have nothing to say right now other than "I think you're wrong". Good note!

If you think two points and a question are nothing, then I can't help you.