Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That doesn't seem to be what they're aiming for here. The goal is supposed to be a new UI that looks and functions very similar to today's.

That's too bad, in a way. One thing I'd really like that Thunderbird doesn't offer today is to separate the mail receive/store/send functionality from the reading/writing UI, so I could run the former on my own server and access it from any device on my network.

Obviously there are some relevant standards here and you could set something like this up with enough technical knowledge using other tools that already exist. However, that reduces the potential market by a few orders of magnitude to those who are sufficiently expert with those tools, and then probably by a few orders more for those who have the time to actually do it.



> That's too bad, in a way. One thing I'd really like that Thunderbird doesn't offer today is to separate the mail receive/store/send functionality from the reading/writing UI, so I could run the former on my own server and access it from any device on my network.

Uh, that's exactly what an email server does. Thunderbird is just the client used to access it from any device.


Assuming by "email server" you mean an SMTP server, that's not quite what I'm talking about. What I'm looking for is more akin to a mail store, an IMAP server, and functionality for sending and receiving via actual SMTP server(s). That's a separate set of responsibilities to reading or composing messages, which would just need something like an IMAP-compatible client. And all of those are separate responsibilities to a full SMTP server with all the administrative overheads that comes with.

You could do the back office part of what I'm talking about with tools like Dovecot and fetchmail today, running on a Linux server with a standard Maildir backing store, and then you could run Thunderbird purely for its IMAP client capabilities as a front-end, but setting it all up and maintaining it is a horrendous hassle and it's far too technically demanding for most users anyway.

However, separating the receive/store/send responsibilities from the read/write responsibilities would mean you could have a single store on any server with relatively straightforward set-up to actually send and receive mail, which you could then access from any device on your network (or over a VPN or the Internet if it's running on a remotely accessible box), without the risks and overheads of both running your own SMTP server and trying to get mail from it actually accepted anywhere else these days.

Now that everyone's got PCs, laptops, tablets, phones, and who knows what else, I think this is probably the single most limiting problem with traditional offline email clients compared to all the hosted webmail services, but it shouldn't be necessary to incur all the downsides of those hosted webmail services just to access your mail from different devices.


IMAP is that single store. Setting up a server just for that would be just as impossible for most users as settings up a mail server would be.


An IMAP server alone typically doesn't include the equivalents of fetchmail and the like. It just provides a protocol for remotely accessing the mail store.

However, I don't see why you think it would be impossible for most users to set up what I'm describing. If they can install Thunderbird and configure it to retrieve mail from their ISP or GMail or whatever, they could install a two-part system and configure the store part to do the same using exactly the same information.

In particular, just installing both parts on a single PC would work fine and provide equivalent functionality to current standalone mail clients like Thunderbird. You just have the flexibility to connect other devices to the same store and safely access your mail from those as well, or to install the store part on some other place on the network like an office server or maybe a NAS at home if you want to.


> However, I don't see why you think it would be impossible for most users to set up what I'm describing. If they can install Thunderbird and configure it to retrieve mail from their ISP or GMail or whatever, they could install a two-part system and configure the store part to do the same using exactly the same information.

Then to connect from their mobile they have to open ports on their home networks, get a static IP, know what their IP is to enter it on their phone, worry about a whole host of new security issues.

At that point you may as well run a full mail server.


Many ISPs offer a static IP. This is applicable for small businesses as well, and they almost certainly have one. Anyone with VPN on their router to access anything remotely has a way in.

There are difficulties in running a full mail server far beyond this. For example, many ISPs won't let you run one on anything below a high-level business plan without just blocking port 25 and friends at a firewall. Even if you can, many other mail servers will flag anything you send as likely junk mail if you're not running a well-known mail server yourself. For incoming mail, you need something that's going to be up 24/7/365 if you're going to give it as the MX for your domain, and you need to be constantly monitoring for security issues in real time, because if you're even a few hours late with the patch then you're probably running an open relay already and you just made every blacklist on the Internet.

Basically, if you're not big enough to have your own full time IT department, there are huge practical advantages to sending and receiving your mail via a dedicated SMTP server run by someone who does. These are completely unrelated to the usefulness of having a centralised mail store that can be used from anywhere on your network, or beyond if you provide a way in for remote access.


Was going to reply with the same - it is called IMAP




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: