Hacker News Reader

Comment by autoexec | Hacker News Reader

Email is a pretty good way to send short text messages, but it's not great at sending files. The basic protocols are pretty simple and we've got a lot of experience using them. I can see the appeal of email.

There's no way that outlook is the best tool for the job though, and it's no surprise at all that they're having problems with it. It's a complete mess with insane amounts of overhead and bloat if all you want to do is send text. Even the message headers it sends/mangles are trash. It's a pain to work with on the end user side too. I can't imagine that they couldn't have written a basic email client that would do the job better with far fewer problems/resources or used/built off of any number of decades old open source projects.

View on HN

This comment is downvoted, but it is correct. Emailing a file takes roughly 30% more bandwidth than a file transfer protocol (any such protocol, not necessarily FTP) due to mime encoding.

Discussion of the MIME part’s encoding as being an inefficient size is missing the forest for the trees.

The entire message is (or can be) compressed before transmission (eg. When IMAP has DEFLATE enabled).

Just because an intermediate encoding step expands binary to make it text safe doesn’t mean it has to stay uncompressed during the entire existence of that MIMe message.

If all you need is file transfer even the message header is a lot of overhead (how much overhead depends on the client and how many devices handle the message). Mail servers don't always handle large files very well either. Even if they upload correctly downloading can be difficult. It's not uncommon for a single message with a large attachment to clog a mailbox and prevent other messages from being sent/received. That said, I'm not even saying it can't/wont work, just that there's better options for sending files and there are certainly better MUAs than outlook.

This is all conjecture.

I’m not arguing for Outlook. I wouldn’t touch that POS unless I was forced to.

But maybe it’s just easier to not have to teach an astronaut to use another app. If they are using Outlook in space, it’s probably the same app and server they use on the ground.

Of course FTP or RSYNC or whatever would be slightly more efficient for the transfer or more capable or retrying / resuming. I’m not arguing that either.

Sometimes it’s more important that the astronaut doesn’t have to learn another app instead/ system.

Sometimes it’s better to choose a less efficient system that is less prone to accidental destructive. It’s not like anybody ever screwed up a sync command and accidentally wiped a directory or anything.[1]

[1] https://www.reddit.com/r/linuxquestions/comments/1kawpyu/rsy...

But without the intermediate encoding step the compression would give a better result.

Unlikely. If you are talking about adding headers, or encryption, then yeah the compression might give worse result, it's due to more input data and/or encryption increasing the entropy of the signal. Otherwise, transparent encoding should not affect any decent compression algorithms, where frequency and entropy are leveraged.

Find me an example where the Zipped version of a Base64 encoded image was larger than the raw image by more than the length of my comment.

I’ll wait.

They're almost certainly using an Exchange server; Outlook is not (just) an email app. Attachments are not being sent via smtp.

Great, one more thing that can fail. Does anyone remember, that some time ago lots of people were in panic, because Exchange servers had a vulnerability on "high severity" level, and people everywhere had to patch their Exchange servers, if they didn't rent them from a service provider? Can't wait to see that happening again, this time affecting an Exchange server used by astronauts in space!

These aren't mission critical systems, they can lose their email

Reply on news.ycombinator.com