Hacker News Reader

Comment by jasonjayr | Hacker News Reader

"Eudora was specifically designed with the idea that standards are a key to successful adoption. Indeed, the rapid acceptance of the Internet is largely due to the standardization process. Published standards are what allow applications from multiple sources to cooperate with each other. Without standards organizations would only be able to use their own applications together, and not those from outside. Also, by allowing diversity of implementations you achieve a much more robust software ecosystem."

- From the "Windows Eudora Architecture.pdf" in the distribution

View on HN

This is beautiful. One of the "so obvious it's invisible" truths of the modern age, and I nearly forgot that Eudora and other pioneers of the age were making a somewhat risky choice to only support standard protocols and eschew the proprietary mailers. Most of them are now long dead yet POP3, IMAP, SNMP chug along. At the time, though, it wasn't so clear.

Eudora also had (has?) UUCP spool support, for those not yet connected to the Internet. I used it that way originally.

POP3 is horribly inefficient and SNMP is a security disaster waiting to happen. At least POP3 isn’t widely used anymore.

Most likely the post you're replying to meant smtp instear of snmp. Makes more sense for a remark about a mail client. I see this typo more often.

Why is POP3 horribly inefficient? Lack of an equivalent to the IMAP COMPRESS extension?

It's fine if it's used to simply pull down mail to a local spool. The inefficiency complaints usually stem from attempting to maintain mail on a remote server across multiple clients. POP3 does not implement a sufficiently rich protocol to make this possible without downloading the entire spool onto each client.

For example, no searching.

No, it's highly inefficient in the face of latency, because there essentially is no batch fetching primitive. Fetching messages over a high latency connection (e.g. to a server on the other side of Earth) takes forever if you have a lot of messages.

That's addressed by pipelining (rfc2449, published back in 1998). No batch primitive is necessary if the request/response sequence isn't serialized.

The lack of a remote manipulation interface has always been a problem, however.

POP3 is only efficient if you download all mail to the client and immediately remove it from the server. But nobody does that, everyone leaves their mail on the server. Then everytime you synchronize the server has to go through all the mail it has to see what you don’t have, which is very inefficient if you have 10000 mails in your inbox, like most people have these days.

It’s optimized for a usecase that doesn’t exist anymore and it will work in the usecase that does exist while wasting a lot of resources. Truly the worst you can have. It’d be better if it didn’t work at all.

I don't think it is at all fair to call POP3 inefficient on this basis. It is fine if you use it in the way it is intended (and presumably optimised) for. It was designed as a delivery mechanism back when people didn't tend to have permanent connections and space on servers wasn't cheap. Users wanted mail locally for disconnected use and servers wanted rid of it once delivered onward.

Where it is not the right tool for the job, use the tool that is instead (IMAP presumably in this case).

Sure, it’s fine if you need to do something nobody wants. Great.

It seems that something that doesn't meet your needs (but did match many people's requirements in the past and may still meet some people's needs now) exists is causing you some offence.

Have you been "burned" by problems with POP3 in some specific way that has made you feel this bitter towards it rather then using the right tool for a job it presumably isn't right for and moving on? Or are you being forced to use it in some circumstance?

> something nobody wants

You are not everybody. Just because you can't imagine a valid use case these days does not mean that one does not exist. While IMAP-with-local-caching can replace most use cases for POP3, does it replace all of them in an optimal manner?

Whoo-hoo! I'm a nobody!

Me too. Nobody uses it (for large values of nobody).

> But nobody does that, everyone leaves their mail on the server.

Absolutely not. I have a personal e-mail address which is IMAP and a shared mailbox with my wife which is POP (I don't want my mail read if she reads it). Mail clients are configured to leave mail on the server for 1 month. It's not complicated.

I for one use pop3 and am really content with it. I cannot bear the idea of keeping my personal mails on a remote server. And that of having to use a web interface to configure splitting rules via a web interface, unable to easily version control and undestructibly and easily test.

You seem to have a personal (!) problem with POP3. Why is that? Are you forbidden to use IMAP because of it? Are you forced to implement a POP3 server?

Clearly you’ve never had to do tech support for people that inadvertently chose POP3 because in many systems it’s still the default selection, along with the default behavior of deleting mails from the server as you fetch them.

What do you mean the only copy of all my mail is in some bizarro mail client specific proprietary database? Why can’t I also read my mail on my phone? I dropped my laptop in the toilet and now my mail is gone. Isn’t it on the server? Why can’t I use folders? Don’t you have backups?

No, your mail is gone, because you used a protocol designed for the 90s. It’s a great idea if you have a mail account with 10mb quota and you download your mail to a fixed, reliable workstation and you don’t mind if you lose it all if the disk crashes, it doesn’t happen that often. Not hardly as often as laptops getting stolen, Windows breaking itself and phones going bust.

I’m not sure why I need to have personal problems with your pet protocol to have an opinion on it, especially on one that stinks as much as POP3. It’s obsolete.

> I’m not sure why I need to have personal problems with your pet protocol to have an opinion on it, especially on one that stinks as much as POP3. It’s obsolete.

Because you're trying to fight people that use it.

In another comment I write how I use it. Clearly you can lose mail with IMAP too. There is a reason we do backups. Also, people not knowing how to use it or you not liking to deal with these does not make a protocol obsolete.

I have an iMac, a MacBook Pro, an iPad, and an iPhone, and I want to be able to access my email from any of them. POP3 is simply not designed to handle that situation gracefully. If a POP3 client is set to download email and delete it from the server, then the messages get "stuck" on whatever client happened to download it first; if it's set to keep copies of the emails on the server, then it pretty much becomes IMAP. Except stupider, since POP3 doesn't treat "downloaded" and "read" as separate concepts.

While I suspect I'm relatively uncommon in having four devices that I want to be in sync, wanting two or three devices -- computer, phone, and possibly work computer -- to be in sync probably isn't very uncommon at all.

I use POP3 for fetching mail from my remote mail server, and I don't want to keep mail on it (my current pipeline is: mpop > procmail (clamav, spamassassin) > gnus (nnsplit & nnml)). This does not bar me from using IMAP locally to sync mail among my devices (which is a problem I haven't handled yet, mostly because has not really been necessary for me up until now). But because I don't use folders and spam checkers on the remote, and never keep mail there, using IMAP to communicate with it is unnecessary.

Wait. SNMP or SMTP? I'm legitimately asking and not being pedantic because I'm genuinely curious.

SMTP.

Tell that to Gmail people...

Edit: https://news.ycombinator.com/item?id=16830156

Not sure how message expiry is a standards compliance issue. SMTP, MIME and RFC822 et. al. don't say anything about where, how or if the message gets stored once transmitted.

> Not sure how message expiry is a standards compliance issue.

using market-influence to build massive scale expectation for a feature which can't actually be supported by the underlying protocol in an effort to 'embrace and extend' is exactly a standards compliance issue, and precisely what led to microsoft's internet explorer being labeled as an antitrust violation.

One of the commenters on that article wrote:

> Well, I think this works differently. The email just includes a link to a Google webpage with the email. It’s still just an email sitting in your inbox. It doesn’t remove itself automatically.

So it's not a standards issue at all.

It's an abuse of the standard.

The email standard was built so that you can check your email with a client, and view the contents offline at your convenience, archive, back up, etc.

Google's email proposal kills this functionality.

When was the last time I used this, you may ask? On Saturday. I was in one of the slot canyons in Utah with zero signal, and, while taking a break, I wrote several emails in my Opera email client, in response to some messages I've procrastinated writing a response to.

The trickery is that the sender might think they're sending a message over email to the recipient, whereas they are sending the message to Google's servers over an internal protocol, and are sending a link to the message to the recipient over email.

The email standard allows links in emails.

You are missing the spirit of the comment.

This is not a matter of can it be done and be standard, but whether it should be.

That's just as important here.

I'm not missing anything. There's nothing wrong with placing links in emails. The link is good, presumably in and out of gmail, and is clearly a gmail feature, not an email feature. There's no problem here.

When the link is the message, and the user thinks it won't change, or go away, it's a problem.

And when my email client doesn't fetch remote content, it will be a problem :)

So maybe I'll be replying "Why did you send me an empty message?"

And maybe some email list software will have the same problem.

But the email is readable, it has a link to a message online. It is not a change to the standard, since it's in the body, where you can write whatever you like. In fact, it's not even unprecedented, because Cisco has been offering this exact same type of system for years generally for PHI and other sensitive uses.

A URL, or embedded content as part of HTML?

If it were just a URL, even an HTML-enabled client would show just the link. I assumed that it must be embedded content, which would be rendered as a normal-looking message.

Maybe it's both. But even so, I'd just see the link. And generally, I ignore blank messages containing links.

Also, it's not uncommon for email list software to strip HTML, and I doubt that it would decode the HTML before doing so.

How do you even use a mailing list properly with this going on?

The big deal here is users do not get copies of content, instead notifications content is, or may be available.

And that's then. What about searching mail archives? You know just that sort of thing being just a little broken is not an accident.

Or it changes.

"You told me to fuck off"

"Prove it"

Message says hugs and kisses.

That's gonna happen. Count on it, with lame screenshot battles being "proof."

My bank send me a "Secure Cisco Message". That I think was In response to a web message support request. They didn't tell me in what form to accept the response.

It was a message with instructions to save the .html attachment to your hard drive and open it there. It included tons of obfuscated Javascript.

Without opening the message I replied back and told them "Nope. We're not going to communicate this way, this is irresponsible and dangerous."

Yep, they couldn't have made that message look more like phishing if they tried - including poor HTML formatting of the email body. This is how you really know that GPG has failed.

Please understand, I never said the Secure Cisco Message was actually good lol

That's my planned reply.

> The link is good, presumably in and out of gmail

The link is clearly not good out of Google ecosystem. You need to have a Google account to view it. Otherwise, there's nothing stopping the e-mail client (or even recipient's email server) from fetching the link upon receipt.

To be clear: Gmail want to be a UI for sending messages via a proprietary protocol which look like emails to the sender and receiver if they are Gmail users.

If your outgoing emails were silently converted into Snapchat messages (more features! why not! everyone's one Snapchat anyway!), would you be similarly unconcerned?

>and is clearly a gmail feature, not an email feature. There's no problem here.

That's precisely the problem: turning Email into Gmail.

Remember how IE added features to HTML which were IE features, not HTML features? Remember how it wasn't at all a problem?

And some of us don't follow them, for better security.

How do you distinguish between this and, say, e-cards? Blue Mountain has been sending e-mail links to ephemeral content since at least the early 2000s.

Reply on news.ycombinator.com